From james.graham at oracle.com Mon Apr 1 10:36:28 2013 From: james.graham at oracle.com (Jim Graham) Date: Mon, 01 Apr 2013 03:36:28 -0700 Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage & Dasher clipping problem In-Reply-To: References: <515632E7.4010507@oracle.com> Message-ID: <5159632C.8040405@oracle.com> On 3/30/2013 5:25 AM, Laurent Bourg?s wrote: > I would like first try / do simple things: skip segments totally out of the clipping + margin (10%) to avoid the dasher create millions of invisible segments. > it seams simple but check each segment could become a performance bottleneck too ! Two caveats: - For curves, just compare the control points, not the tight curve to save time. Bezier curves are guaranteed to live inside the convex hull of their control points. - For miter joins, you have to adjust that 10%, or whatever margin you use based on the miter limit. I'm assuming you meant "margin = line width + 10%", but it should be "margin = line width * miter limit + 10%", unless the join style is not "MITER" in which case you can treat the miter limit as 1.0. > For complex shapes (curves), it could be interesting to take into account the spatial resolution: for example a curve that represents less than 1 (AA) pixel should be skipped ... it can apply to caps (mitter, bevel, rounded) too! For skipping in the renderer maybe, but if you try to apply that logic in the pre-stroking stage then keep in mind that a very tiny curve could sweep a very large angle and cause a very large number of pixels to be rendered. In the simplest case stroking a zero length line segment with square caps will minimally draw a rectangle that is lw x lw. Think of a tiny person holding a very long pole across their chest. As they move the pole sweeps out the line's area. They may spin in place, and you might think to ignore that move, but that pole is going to be sweeping out a huge area around them. > Do you look at the java2D Pisces code, Jim ? > I think it quite difficult to understand (only few comments / explanations ...). Does somebody know if there is some docs on this implementation / algorithms ? I have worked extensively with it. Denis Lila did the major work to create what it is today, but I was doing the code reviews every step of the way. We've also integrated a version of it into JavaFX and ported it to native code as part of that project. ...jim From bourges.laurent at gmail.com Mon Apr 1 21:20:56 2013 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Mon, 1 Apr 2013 23:20:56 +0200 Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?) In-Reply-To: References: <51506136.4020909@oracle.com> <51508139.9000507@oracle.com> <51549C3F.1020301@oracle.com> <5154ACCD.5090105@oracle.com> Message-ID: Andra & Jim, Here is the current status of my patch alpha version: http://jmmc.fr/~bourgesl/share/java2d-pisces/ There is still a lot to be done: clean-up, stats, pisces class instance recycling (renderer, stroker ...) and of course sizing correctly initial arrays (dirty or clean) in the RendererContext (thread local storage). For performance reasons, I am using now RendererContext members first (cache for rowAARLE for example) before using ArrayCaches (dynamic arrays). I provided the patch as zip file and few benchmark using Andrea's MapBench (Xmx128m): - OpenJDK 8 PATCHED: Testing file /home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser 1 threads and 20 loops per thread, time: 3687 ms 2 threads and 20 loops per thread, time: 3693 ms 4 threads and 20 loops per thread, time: 6849 ms Loading drawing commands from file: /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213} Testing file /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser 1 threads and 20 loops per thread, time: 27266 ms 2 threads and 20 loops per thread, time: 33628 ms 4 threads and 20 loops per thread, time: 61577 ms - OpenJDK 8 REFERENCE: Testing file /home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser 1 threads and 20 loops per thread, time: 3982 ms 2 threads and 20 loops per thread, time: 4852 ms 4 threads and 20 loops per thread, time: 8842 ms Loading drawing commands from file: /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213} Testing file /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser 1 threads and 20 loops per thread, time: 55889 ms 2 threads and 20 loops per thread, time: 77691 ms 4 threads and 20 loops per thread, time: 141981 ms - Oracle JDK8 DUCTUS: Testing file /home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser 1 threads and 20 loops per thread, time: 1894 ms 2 threads and 20 loops per thread, time: 3905 ms 4 threads and 20 loops per thread, time: 7485 ms Loading drawing commands from file: /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213} Testing file /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser 1 threads and 20 loops per thread, time: 20911 ms 2 threads and 20 loops per thread, time: 39297 ms 4 threads and 20 loops per thread, time: 103392 ms As you can see, patched openJdk8 performs better and it is very noticeable on big drawings (dc_shp_alllayers_2013-00-30-07-00-47.ser) and better than ductus with 2 threads !! Laurent 2013/3/30 Andrea Aime > On Sat, Mar 30, 2013 at 2:01 PM, Laurent Bourg?s < > bourges.laurent at gmail.com> wrote: > >> - clipping issues (dasher, stroker) and spatial resolution (no cpu/memory >> waste) >> > > I see, yes. Indeed in the GeoServer code we already work around some of > those issues by > clipping the geometries read from the database to the graphics2d viewport > before giving them > to the renderer, we had to do that both for performance issues and to > avoid OOM errors > when basic stroke with dasharray is used against a line that is many times > longer than the > current display area > > >> I don't have anything ready, the existing code loads data from spatial >>> database, sets up styles from XML descriptions, turns each spatial db >>> geomety in java shapes >>> and so on. But I guess I could concoct something close enough. >>> I'm writing some code to gather statistics about the shapes that are >>> actually painted (scrolling over the path iterators) and then I'll try to >>> make a randomized >>> shape painter that gets close to those stats. >>> >> >> Great news ! I am waiting your test code to perform few benchmarks. >> >> I am using J2DBench but it does not perform such complex drawing (complex >> shapes ...) or multi threading tests (parallel drawings on buffered images) >> > > Ok, I've created a "MapBench" by serializing shapes, strokes and fills > from a real GeoServer instance to disk, and have them > play in a simple multithreaded test harness. > What you get in the output is not exactly the maps generated by GeoServer > since we use a number of tricks to speed up rendering, > including painting over multiple drawing surfaces (the serializer only > handles one), also, some maps have text showing up because > in order to pain "labels along a line" we actually turn the chars into > shapes and place them along the line, but those labels that we > can predict are "straight" are painted with drawGlyphVector so they won't > show up (haven't built a serialization for that case). > > Regardless, the test should be good enough to test both performance and > scalability. > Here is the package: http://demo.geo-solutions.it/share/mapbench.zip > > It contains: > * ShapeDumpingGraphics2D, a Graphics2D wrapper writing on disk all > draw(Shape) and > fill(Shape) commands issued to it > * A bunch of *.ser files, that are the serialized drawing command sequences > * A bunch of *.png files, which are the rendered versions of the .ser > files (for reference) > * MapDisplay, which reads all *.ser files from a directory and displays > them in JFrame and > generates the .png files as well > * MapBench, which reads all *.ser files from a directory and repeatedly > paints them in a loop > with a growing number of threads > * Two txt files with the timings of the benchmarks on my machine for > Oracle JDK 7 and > OpenJDK 7, here is an example comparison: > > OpenJDK7: > Testing file /tmp/dc_boulder_2013-13-30-06-13-17.ser > 1 threads and 20 loops per thread, time: 3340 ms > 2 threads and 20 loops per thread, time: 3688 ms > 4 threads and 20 loops per thread, time: 4665 ms > 8 threads and 20 loops per thread, time: 7343 ms > > Oracle JDK 7: > Warm up took 29516 ms > Testing file /tmp/dc_boulder_2013-13-30-06-13-17.ser > 1 threads and 20 loops per thread, time: 1754 ms > 2 threads and 20 loops per thread, time: 2878 ms > 4 threads and 20 loops per thread, time: 6792 ms > 8 threads and 20 loops per thread, time: 14275 ms > > As you can see ductus is significantly faster than pisces, but it has > serious scalability > issues, while pisces scales up a lot better. > > The code has been put together in a haste, sorry for the lack of comments, > hopefully it is > simple enough that it's usable anyways. > > Cheers > Andrea > > > -- > == > Our support, Your Success! Visit http://opensdi.geo-solutions.it for more > information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > ------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.xu at oracle.com Mon Apr 1 22:16:57 2013 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 01 Apr 2013 15:16:57 -0700 Subject: [OpenJDK 2D-Dev] Review Request: JDK-8000406 - change files using @GenerateNativeHeader to use @Native Message-ID: <515A0759.5070602@oracle.com> Hi All, In this fix, I have updated files in JDK libraries to use @Native annotation instead of @GenerateNativeHeader to mark classes that contain no native methods but constants used by native codes. @GenerateNativeHeader was added earlier in the development for JDK8."This has proved problematic for some core classes with respect to Jigsaw, since the use of such an annotation creates a compile-time dependency from the base module to the module containing javax.tools, and the base module should not have any dependencies." After switching to @Native annotation, the dependency problem will be solved as java.lang.annotation.Native is in the proposed base module. In addition, the annotation has been refined not to be on the class level but on the constants themselves, which also makes the generated header files much cleaner. This effort is part of JDK-8000404. After jdk libraries uptaking the annotation changes, @GenerateNativeHeader annotation will be removed completely. CCC: http://ccc.us.oracle.com/8000404 webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/ Thanks for your feedback! -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Apr 2 08:12:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 02 Apr 2013 09:12:49 +0100 Subject: [OpenJDK 2D-Dev] Review Request: JDK-8000406 - change files using @GenerateNativeHeader to use @Native In-Reply-To: <515A0759.5070602@oracle.com> References: <515A0759.5070602@oracle.com> Message-ID: <515A9301.7030800@oracle.com> On 01/04/2013 23:16, Dan Xu wrote: > Hi All, > > In this fix, I have updated files in JDK libraries to use @Native > annotation instead of @GenerateNativeHeader to mark classes that > contain no native methods but constants used by native codes. > > @GenerateNativeHeader was added earlier in the development for > JDK8."This has proved problematic for some core classes with respect > to Jigsaw, since the use of such an annotation creates a compile-time > dependency from the base module to the module containing javax.tools, > and the base module should not have any dependencies." After switching > to @Native annotation, the dependency problem will be solved as > java.lang.annotation.Native is in the proposed base module. In > addition, the annotation has been refined not to be on the class level > but on the constants themselves, which also makes the generated header > files much cleaner. > > This effort is part of JDK-8000404. After jdk libraries uptaking the > annotation changes, @GenerateNativeHeader annotation will be removed > completely. > > CCC: http://ccc.us.oracle.com/8000404 > webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/ > > Thanks for your feedback! > > -Dan This is great work - thank you for doing this. As the majority of the changed code is in the 2d/awt/client area then I hope that you will get timely reviews from those areas. The main thing with a change like this is that the changes build on all platforms and I've know you've verified that. I skimmed through the webrev and don't see anything obviously wrong. I focused mostly on the non-client code and they all look right. It's interesting that @GenerateNativeHeader was added to several classes with native methods, I don't know why that was the case. I was also unaware that we had Haskell code in the build. So thumbs up from me. I assume you or Jon will remove GenerateNativeHeader from the langtools repository once your changes are pushed. -Alan From anthony.petrov at oracle.com Tue Apr 2 12:07:38 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 02 Apr 2013 16:07:38 +0400 Subject: [OpenJDK 2D-Dev] Review Request: JDK-8000406 - change files using @GenerateNativeHeader to use @Native In-Reply-To: <515A0759.5070602@oracle.com> References: <515A0759.5070602@oracle.com> Message-ID: <515ACA0A.4000809@oracle.com> Hi Dan, Changes to awt code look fine to me. -- best regards, Anthony On 4/2/2013 2:16, Dan Xu wrote: > Hi All, > > In this fix, I have updated files in JDK libraries to use @Native > annotation instead of @GenerateNativeHeader to mark classes that > contain no native methods but constants used by native codes. > > @GenerateNativeHeader was added earlier in the development for JDK8. > "This has proved problematic for some core classes with respect to > Jigsaw, since the use of such an annotation creates a compile-time > dependency from the base module to the module containing javax.tools, > and the base module should not have any dependencies." After switching > to @Native annotation, the dependency problem will be solved as > java.lang.annotation.Native is in the proposed base module. In addition, > the annotation has been refined not to be on the class level but on the > constants themselves, which also makes the generated header files much > cleaner. > > This effort is part of JDK-8000404. After jdk libraries uptaking the > annotation changes, @GenerateNativeHeader annotation will be removed > completely. > > CCC: http://ccc.us.oracle.com/8000404 > webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/ > > Thanks for your feedback! > > -Dan From philip.race at oracle.com Tue Apr 2 19:37:05 2013 From: philip.race at oracle.com (Phil Race) Date: Tue, 02 Apr 2013 12:37:05 -0700 Subject: [OpenJDK 2D-Dev] Review Request: JDK-8000406 - change files using @GenerateNativeHeader to use @Native In-Reply-To: <515A0759.5070602@oracle.com> References: <515A0759.5070602@oracle.com> Message-ID: <515B3361.6080503@oracle.com> The addition of @Native to various lines in SunGraphics2D.java look to have pushed them >80 chars and it looks to me as if previously the author took some care to limit it. Moreover the indentation of the comment block `on lines 127-130 is no longer aligned. Maybe it would be easier for that case to put the annotation on the line above as in @Native static final int FOO ... Otherwise looks OK, looks like you found files that had @GenerateNativeHeaders that didn't need it and cleaned those up, and in native sources removed unneeded header file imports too. I do have a background question about how it works. There is an implication here that only the constants with @native might be included in generated header files. Is that true ? Whereas if a class has native method declarations, then it doesn't need these annotations, but you get all constants in the header file. Is that right ? -phil. On 4/1/13 3:16 PM, Dan Xu wrote: > Hi All, > > In this fix, I have updated files in JDK libraries to use @Native > annotation instead of @GenerateNativeHeader to mark classes that > contain no native methods but constants used by native codes. > > @GenerateNativeHeader was added earlier in the development for > JDK8."This has proved problematic for some core classes with respect > to Jigsaw, since the use of such an annotation creates a compile-time > dependency from the base module to the module containing javax.tools, > and the base module should not have any dependencies." After switching > to @Native annotation, the dependency problem will be solved as > java.lang.annotation.Native is in the proposed base module. In > addition, the annotation has been refined not to be on the class level > but on the constants themselves, which also makes the generated header > files much cleaner. > > This effort is part of JDK-8000404. After jdk libraries uptaking the > annotation changes, @GenerateNativeHeader annotation will be removed > completely. > > CCC: http://ccc.us.oracle.com/8000404 > webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/ > > Thanks for your feedback! > > -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.duigou at oracle.com Tue Apr 2 20:41:43 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 2 Apr 2013 13:41:43 -0700 Subject: [OpenJDK 2D-Dev] requesting bug id for error in fontmanager when no fonts are installed - RHBZ#862355 In-Reply-To: <515AC749.5070306@redhat.com> References: <515AC749.5070306@redhat.com> Message-ID: <396F24C1-93F6-4C49-8CF1-39681E994E5F@oracle.com> This request should be made on the 2d-dev at openjdk.java.net list where the change will be reviewed. Mike On Apr 2 2013, at 04:55 , Jiri Vanek wrote: > Hi! > > When openjdk is used on headless devices (with no fonts), then it crashes. See eg https://bugzilla.redhat.com/show_bug.cgi?id=862355. > I have patch (not 100% finished) for fontconfig manager for this, built, and tested. (deeply only on linux). To move forward with this issue I would like to ask for bug id in your bugzilla. > > With kind regards > Jiri Vanek From lana.steuck at oracle.com Wed Apr 3 02:07:52 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 03 Apr 2013 02:07:52 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jaxp: 2 new changesets Message-ID: <20130403020811.47D724856D@hg.openjdk.java.net> Changeset: a46d69a1a8ec Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/a46d69a1a8ec Added tag jdk8-b82 for changeset d5a58291f09a ! .hgtags Changeset: f5f40094ffcc Author: katleman Date: 2013-03-28 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/f5f40094ffcc Added tag jdk8-b83 for changeset a46d69a1a8ec ! .hgtags From lana.steuck at oracle.com Wed Apr 3 02:07:49 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 03 Apr 2013 02:07:49 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk8/2d: 8 new changesets Message-ID: <20130403020750.E236F4856B@hg.openjdk.java.net> Changeset: e2057191f6da Author: omajid Date: 2013-03-18 10:47 -0400 URL: http://hg.openjdk.java.net/jdk8/2d/rev/e2057191f6da 8010030: Allow configure to detect if EC implementation is present Reviewed-by: andrew, dholmes ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in Changeset: 29153d0df68f Author: omajid Date: 2013-03-19 11:25 -0400 URL: http://hg.openjdk.java.net/jdk8/2d/rev/29153d0df68f 8010277: Configure doesn't fail when Xrender.h is missing Reviewed-by: andrew ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: 466685ba01bf Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/rev/466685ba01bf Added tag jdk8-b82 for changeset 29153d0df68f ! .hgtags Changeset: d409b4cdb74f Author: katleman Date: 2013-03-28 10:53 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/rev/d409b4cdb74f Added tag jdk8-b83 for changeset 466685ba01bf ! .hgtags Changeset: 19a59a13b3ef Author: dholmes Date: 2013-03-14 01:41 -0400 URL: http://hg.openjdk.java.net/jdk8/2d/rev/19a59a13b3ef 8009428: Revert changes to $ substitution performed as part of nashorn integration Reviewed-by: alanb, erikj ! common/makefiles/MakeBase.gmk Changeset: 4984ac509993 Author: lana Date: 2013-03-15 23:08 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/rev/4984ac509993 Merge Changeset: 477d18509ecb Author: lana Date: 2013-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/rev/477d18509ecb Merge Changeset: a1bb1a0df1fa Author: lana Date: 2013-04-01 21:34 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/rev/a1bb1a0df1fa Merge From lana.steuck at oracle.com Wed Apr 3 02:07:49 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 03 Apr 2013 02:07:49 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/corba: 6 new changesets Message-ID: <20130403020759.0A05A4856C@hg.openjdk.java.net> Changeset: a45bb25a67c7 Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/corba/rev/a45bb25a67c7 Added tag jdk8-b82 for changeset 48e1bc77004d ! .hgtags Changeset: 14f1babaf548 Author: katleman Date: 2013-03-28 10:53 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/corba/rev/14f1babaf548 Added tag jdk8-b83 for changeset a45bb25a67c7 ! .hgtags Changeset: c3ec80715805 Author: mfang Date: 2013-03-25 16:53 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/corba/rev/c3ec80715805 8010521: jdk8 l10n resource file translation update 2 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp Changeset: 910af9c3f338 Author: mfang Date: 2013-03-25 18:03 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/corba/rev/910af9c3f338 Merge Changeset: 7d7a009d5fbd Author: lana Date: 2013-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/corba/rev/7d7a009d5fbd Merge Changeset: 928f8b888deb Author: lana Date: 2013-04-01 21:34 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/corba/rev/928f8b888deb Merge From lana.steuck at oracle.com Wed Apr 3 02:07:49 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 03 Apr 2013 02:07:49 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jaxws: 5 new changesets Message-ID: <20130403020815.8EC8E4856E@hg.openjdk.java.net> Changeset: a1dcc0d83da1 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/jaxws/rev/a1dcc0d83da1 Added tag jdk8-b82 for changeset d8d8032d02d7 ! .hgtags Changeset: 54c29eb352e7 Author: katleman Date: 2013-03-28 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/jaxws/rev/54c29eb352e7 Added tag jdk8-b83 for changeset a1dcc0d83da1 ! .hgtags Changeset: 0ab59cba6167 Author: jjg Date: 2013-03-18 18:34 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/jaxws/rev/0ab59cba6167 8007803: Implement javax.lang.model API for Type Annotations Reviewed-by: darcy ! src/share/jaxws_classes/com/sun/tools/internal/jxc/model/nav/ApNavigator.java Changeset: 2476e1f2afa5 Author: lana Date: 2013-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/jaxws/rev/2476e1f2afa5 Merge Changeset: 5773e3fc8380 Author: lana Date: 2013-04-01 21:35 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/jaxws/rev/5773e3fc8380 Merge From lana.steuck at oracle.com Wed Apr 3 02:07:59 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 03 Apr 2013 02:07:59 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/nashorn: 17 new changesets Message-ID: <20130403020819.1EB6C4856F@hg.openjdk.java.net> Changeset: 053d7c55dc82 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/053d7c55dc82 Added tag jdk8-b82 for changeset 5759f600fcf7 ! .hgtags Changeset: fbbdef940138 Author: katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/fbbdef940138 Added tag jdk8-b83 for changeset 053d7c55dc82 ! .hgtags Changeset: c54e218333be Author: sundar Date: 2013-03-12 18:12 +0530 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/c54e218333be 8009757: Package access clean up and refactoring Reviewed-by: jlaskey, lagergren, attila ! docs/JavaScriptingProgrammersGuide.html ! docs/source/javaarray.js ! make/build.xml ! make/java.security.override ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java + src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js ! src/jdk/nashorn/internal/runtime/resources/parser.js ! test/script/basic/JDK-8008448.js ! test/script/basic/NASHORN-401.js ! test/script/basic/consstring.js ! test/script/basic/fileline.js ! test/script/basic/javainnerclasses.js ! test/script/basic/list.js ! test/script/basic/map.js ! test/script/basic/stdin.js ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED ! test/script/sandbox/reflection.js - test/script/sandbox/reflection.js.EXPECTED ! test/script/sandbox/unsafe.js - test/script/sandbox/unsafe.js.EXPECTED ! test/script/trusted/urlreader.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java - test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java ! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java - test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java - test/src/jdk/nashorn/internal/test/models/DessertTopping.java - test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java - test/src/jdk/nashorn/internal/test/models/FinalClass.java - test/src/jdk/nashorn/internal/test/models/FloorWax.java - test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java - test/src/jdk/nashorn/internal/test/models/NonPublicClass.java - test/src/jdk/nashorn/internal/test/models/OuterClass.java - test/src/jdk/nashorn/internal/test/models/OverloadedSam.java - test/src/jdk/nashorn/internal/test/models/OverrideObject.java - test/src/jdk/nashorn/internal/test/models/StringArgs.java - test/src/jdk/nashorn/internal/test/models/Toothpaste.java + test/src/jdk/nashorn/test/models/ConstructorWithArgument.java + test/src/jdk/nashorn/test/models/DessertTopping.java + test/src/jdk/nashorn/test/models/DessertToppingFloorWaxDriver.java + test/src/jdk/nashorn/test/models/FinalClass.java + test/src/jdk/nashorn/test/models/FloorWax.java + test/src/jdk/nashorn/test/models/Nashorn401TestSubject.java + test/src/jdk/nashorn/test/models/NoAccessibleConstructorClass.java + test/src/jdk/nashorn/test/models/NonPublicClass.java + test/src/jdk/nashorn/test/models/OuterClass.java + test/src/jdk/nashorn/test/models/OverloadedSam.java + test/src/jdk/nashorn/test/models/OverrideObject.java + test/src/jdk/nashorn/test/models/SourceHelper.java + test/src/jdk/nashorn/test/models/StringArgs.java + test/src/jdk/nashorn/test/models/Toothpaste.java Changeset: e15806b9d716 Author: lagergren Date: 2013-03-12 15:30 +0100 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/e15806b9d716 8009718: Lazy execution architecture continued - ScriptFunctionData is either final or recompilable. Moved ScriptFunctionData creation logic away from runtime to compile time. Prepared for method generation/specialization. Got rid of ScriptFunctionImplTrampoline whose semantics could be done as part of the relinking anyway. Merge with the lookup package change. Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java - src/jdk/nashorn/internal/ir/annotations/ChildNode.java - src/jdk/nashorn/internal/ir/annotations/ParentNode.java ! src/jdk/nashorn/internal/ir/annotations/Reference.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java - src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java + src/jdk/nashorn/internal/runtime/CompiledFunction.java + src/jdk/nashorn/internal/runtime/CompiledFunctions.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAException.java + src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java + src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java - src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! test/script/currently-failing/JDK-8006529.js + test/script/currently-failing/clone_ir.js Changeset: 60684aeba89c Author: sundar Date: 2013-03-12 21:17 +0530 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/60684aeba89c 8009868: For loop with "true" as condition results in AssertionError in codegen Reviewed-by: jlaskey, hannesw, lagergren ! src/jdk/nashorn/internal/codegen/Lower.java + test/script/basic/JDK-8009868.js Changeset: 390d44ba90cf Author: lagergren Date: 2013-03-14 14:49 +0100 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/390d44ba90cf 8009982: Lazy execution bugfix. Added lazy sunspider unit test. Added mandreel to compile-octane test. Fixed warnings Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpResult.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js + test/script/basic/runsunspider-eager.js + test/script/basic/runsunspider-lazy.js ! test/script/basic/runsunspider.js Changeset: d5d80b52cf1c Author: lagergren Date: 2013-03-15 16:07 +0100 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/d5d80b52cf1c 8010147: Forgot to add EXPECTED files for lazy and eager sunspider test Reviewed-by: sundar, jlaskey + test/script/basic/runsunspider-eager.js.EXPECTED + test/script/basic/runsunspider-lazy.js.EXPECTED - test/script/basic/runsunspider.js.EXPECTED Changeset: 4daacf8a25ef Author: sundar Date: 2013-03-15 21:52 +0530 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/4daacf8a25ef 8010145: removed workaround "init.js" in nashorn repo Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/Formatter.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/api/scripting/resources/engine.js - src/jdk/nashorn/api/scripting/resources/init.js Changeset: 3b0a0d9d51f0 Author: sundar Date: 2013-03-18 21:03 +0530 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/3b0a0d9d51f0 8010199: javax.script.Invocable implementation for nashorn does not return null when matching functions are missing Reviewed-by: lagergren, jlaskey ! bin/jjs ! bin/jjssecure ! bin/nashorn ! bin/nashornsecure ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java + test/script/basic/JDK-8010199.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 606a1946e3e2 Author: jlaskey Date: 2013-03-19 11:03 -0300 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/606a1946e3e2 8009969: CodeCoverage should use template Reviewed-by: jlaskey, sundar Contributed-by: pavel.stepanov at oracle.com ! make/build.xml ! make/code_coverage.xml ! make/project.properties Changeset: 4be452026847 Author: attila Date: 2013-03-23 00:58 +0100 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/4be452026847 8010652: Eliminate non-child references in Block/FunctionNode, and make few node types immutable Reviewed-by: jlaskey, lagergren ! make/project.properties ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/DoWhileNode.java ! src/jdk/nashorn/internal/ir/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java + src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Location.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/PropertyNode.java - src/jdk/nashorn/internal/ir/ReferenceNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/TypeOverride.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/basic/JDK-8006755.js ! test/script/basic/NASHORN-837.js ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java Changeset: ae4ef3102d9c Author: lagergren Date: 2013-03-25 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/ae4ef3102d9c 8017010: index evaluation to a temporary location for index operator much change temporaries to slots, but never scoped vars Reviewed-by: hannesw, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java + test/script/basic/JDK-8017010.js + test/script/basic/JDK-8017010.js.EXPECTED ! test/script/basic/NASHORN-258.js ! test/script/basic/NASHORN-258.js.EXPECTED Changeset: 15dac7439921 Author: sundar Date: 2013-03-25 18:20 +0530 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/15dac7439921 8010709: org on the top level doesn't resolve Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/objects/Global.java + test/script/basic/JDK-8010709.js Changeset: 43e40c08e7f8 Author: lagergren Date: 2013-03-26 08:42 +0100 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/43e40c08e7f8 8010706: -Dnashorn.args system property to create command lines to wrapped nashorn.jar:s Reviewed-by: hannesw, sundar ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/runtime/options/Options.java Changeset: ed60078f0a80 Author: sundar Date: 2013-03-26 18:26 +0530 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/ed60078f0a80 8010720: Linkage problem with java.lang.String.length() Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/basic/JDK-8010720.js Changeset: db8a33cb22b8 Author: lana Date: 2013-03-26 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/db8a33cb22b8 Merge - src/jdk/nashorn/api/scripting/resources/init.js - src/jdk/nashorn/internal/ir/ReferenceNode.java - src/jdk/nashorn/internal/ir/annotations/ChildNode.java - src/jdk/nashorn/internal/ir/annotations/ParentNode.java - src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java - src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java - test/script/basic/runsunspider.js.EXPECTED - test/script/sandbox/reflection.js.EXPECTED - test/script/sandbox/unsafe.js.EXPECTED - test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java - test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java - test/src/jdk/nashorn/internal/test/models/DessertTopping.java - test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java - test/src/jdk/nashorn/internal/test/models/FinalClass.java - test/src/jdk/nashorn/internal/test/models/FloorWax.java - test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java - test/src/jdk/nashorn/internal/test/models/NonPublicClass.java - test/src/jdk/nashorn/internal/test/models/OuterClass.java - test/src/jdk/nashorn/internal/test/models/OverloadedSam.java - test/src/jdk/nashorn/internal/test/models/OverrideObject.java - test/src/jdk/nashorn/internal/test/models/StringArgs.java - test/src/jdk/nashorn/internal/test/models/Toothpaste.java Changeset: 999cc1bf5520 Author: lana Date: 2013-04-01 21:42 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/999cc1bf5520 Merge - src/jdk/nashorn/api/scripting/resources/init.js - src/jdk/nashorn/internal/ir/ReferenceNode.java - src/jdk/nashorn/internal/ir/annotations/ChildNode.java - src/jdk/nashorn/internal/ir/annotations/ParentNode.java - src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java - src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java - test/script/basic/runsunspider.js.EXPECTED - test/script/sandbox/reflection.js.EXPECTED - test/script/sandbox/unsafe.js.EXPECTED - test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java - test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java - test/src/jdk/nashorn/internal/test/models/DessertTopping.java - test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java - test/src/jdk/nashorn/internal/test/models/FinalClass.java - test/src/jdk/nashorn/internal/test/models/FloorWax.java - test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java - test/src/jdk/nashorn/internal/test/models/NonPublicClass.java - test/src/jdk/nashorn/internal/test/models/OuterClass.java - test/src/jdk/nashorn/internal/test/models/OverloadedSam.java - test/src/jdk/nashorn/internal/test/models/OverrideObject.java - test/src/jdk/nashorn/internal/test/models/StringArgs.java - test/src/jdk/nashorn/internal/test/models/Toothpaste.java From lana.steuck at oracle.com Wed Apr 3 02:08:15 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 03 Apr 2013 02:08:15 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/langtools: 30 new changesets Message-ID: <20130403021018.E6DE048570@hg.openjdk.java.net> Changeset: 22ba3f92d4ae Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/22ba3f92d4ae Added tag jdk8-b82 for changeset 825da6847791 ! .hgtags Changeset: 35cef52b0023 Author: katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/35cef52b0023 Added tag jdk8-b83 for changeset 22ba3f92d4ae ! .hgtags Changeset: eb0198033c5c Author: jfranck Date: 2013-03-13 22:03 +0100 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/eb0198033c5c 8006547: Repeating annotations: No Target on container annotation with all targets on base annotation gives compiler error Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/repeatingAnnotations/DefaultTarget.java + test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.java + test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.out + test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.java + test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.out + test/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer.java + test/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer2.java Changeset: e0ef84e33167 Author: bpatel Date: 2013-03-13 14:47 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/e0ef84e33167 8009684: Default top left frame should be "All Packages" in the generated javadoc documentation Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java Changeset: 82dc1e827c2a Author: dholmes Date: 2013-03-14 01:45 -0400 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/82dc1e827c2a 8009429: Miscellaneous profiles cleanup Reviewed-by: jjg, alanb ! src/share/classes/com/sun/tools/javac/sym/Profiles.java Changeset: 2e21ecd7a5ad Author: vromero Date: 2013-03-14 08:30 +0000 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/2e21ecd7a5ad 8008582: jtreg failures after conversion of shell tests to Java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/ArrayUtils.java ! test/tools/javac/4846262/CheckEBCDICLocaleTest.java ! test/tools/javac/ClassPathTest/ClassPathTest.java ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java ! test/tools/javac/lib/ToolBox.java ! test/tools/javac/links/LinksTest.java ! test/tools/javac/newlines/NewLineTest.java ! test/tools/javah/6257087/T6257087.java ! test/tools/javah/constMacroTest/ConstMacroTest.java ! test/tools/javap/stackmap/StackmapTest.java Changeset: fd3fdaff0257 Author: mchung Date: 2013-03-14 10:33 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/fd3fdaff0257 8005428: Update jdeps to read the same profile information as by javac Reviewed-by: alanb ! make/netbeans/langtools/nbproject/project.xml ! src/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java + src/share/classes/com/sun/tools/jdeps/Profiles.java ! src/share/classes/com/sun/tools/jdeps/resources/jdeps.properties - src/share/classes/com/sun/tools/jdeps/resources/jdk.properties ! test/tools/jdeps/Basic.java ! test/tools/jdeps/p/Foo.java + test/tools/jdeps/profiles.properties Changeset: fbbf5376e7e4 Author: rfield Date: 2013-03-14 22:54 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/fbbf5376e7e4 8010010: NPE generating serializedLambdaName for nested lambda Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaLambdaSerialized.java Changeset: fa24eba012bd Author: vromero Date: 2013-03-15 09:02 +0000 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/fa24eba012bd 5053846: javac: MethodRef entries are duplicated in the constant pool Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T5053846/MethodRefDupInConstantPoolTest.java Changeset: 195b71850b56 Author: mnunez Date: 2013-03-15 13:39 +0100 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/195b71850b56 8007767: TargetAnnoCombo.java need to be updated to add a new test mode Reviewed-by: jjg, strarup ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java ! test/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java - test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java Changeset: a3049f4a7987 Author: lana Date: 2013-03-15 23:46 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/a3049f4a7987 Merge Changeset: 1f8c28134ffc Author: jjg Date: 2013-03-18 08:46 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/1f8c28134ffc 8005220: RFE to write javap tests for repeating annotations. Reviewed-by: jjg Contributed-by: peter.jensen at oracle.com + test/tools/javap/output/RepeatingTypeAnnotations.java + test/tools/javap/output/Tester.java Changeset: 40adaf938847 Author: jjg Date: 2013-03-18 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/40adaf938847 8008425: Remove interim new javax.lang.model API for type-annotations Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java - src/share/classes/javax/lang/model/type/AnnotatedType.java ! src/share/classes/javax/lang/model/type/ExecutableType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/Types.java Changeset: 97f6839673d6 Author: jjg Date: 2013-03-18 18:33 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/97f6839673d6 8007803: Implement javax.lang.model API for Type Annotations Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java + src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java + src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/type/ExecutableType.java ! src/share/classes/javax/lang/model/type/TypeMirror.java ! src/share/classes/javax/lang/model/util/Types.java Changeset: a4913ea9bb62 Author: darcy Date: 2013-03-19 13:10 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/a4913ea9bb62 8010179: Remove transitional target values from javac Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java ! test/tools/javac/profiles/ProfileOptionTest.java Changeset: 578eb3dd111d Author: jjg Date: 2013-03-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/578eb3dd111d 8010315: doclint errors in javac public API Reviewed-by: darcy ! make/build.xml ! src/share/classes/com/sun/source/util/DocTreeScanner.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/type/ExecutableType.java Changeset: a03c4a86ea2b Author: jjg Date: 2013-03-19 17:04 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/a03c4a86ea2b 8010361: fix some langtools findbugs issues Reviewed-by: darcy ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/javah/Util.java ! src/share/classes/com/sun/tools/javap/StackMapWriter.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java Changeset: 9cf17b7a5fe7 Author: jjg Date: 2013-03-19 17:05 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/9cf17b7a5fe7 8010333: Remove com.sun.tools.javac.Server Reviewed-by: darcy - src/share/classes/com/sun/tools/javac/Server.java Changeset: 74d7f9bcac93 Author: jjg Date: 2013-03-19 19:16 -0700 URL: http://hg.openjdk.java.net/jdk8/2d/langtools/rev/74d7f9bcac93 8010317: DocLint incorrectly reports some 
 tags as empty
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/Checker.java
+ test/tools/doclint/EmptyPreTest.java

Changeset: 972474640b7d
Author:    darcy
Date:      2013-03-20 17:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/972474640b7d

8010364: Clarify javax.lang.model API for Type Annotations
Reviewed-by: jjg, abuckley

! src/share/classes/javax/lang/model/AnnotatedConstruct.java
! src/share/classes/javax/lang/model/type/ExecutableType.java

Changeset: cc38a6723663
Author:    mcimadamore
Date:      2013-03-22 12:38 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/cc38a6723663

8009649: Lambda back-end should generate invokespecial for method handles referring to private instance methods
Summary: Private lambda methods should be accessed through invokespecial
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/bytecode/TestLambdaBytecode.java

Changeset: f3814edefb33
Author:    mcimadamore
Date:      2013-03-22 12:39 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/f3814edefb33

8010101: Intersection type cast issues redundant unchecked warning
Summary: Code for checking intersection type cast is incorrectly swapping operands, leading to spurious warnings
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/lambda/Intersection02.java
+ test/tools/javac/lambda/Intersection02.out

Changeset: b6cf07c54c29
Author:    mcimadamore
Date:      2013-03-22 12:41 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/b6cf07c54c29

8009820: AssertionError when compiling java code with two identical static imports
Summary: Speculative attribution is carried out twice with same method symbol in case of static imports
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
+ test/tools/javac/lambda/DoubleStaticImport.java

Changeset: c6728c9addff
Author:    mcimadamore
Date:      2013-03-22 12:43 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/c6728c9addff

8010303: Graph inference: missing incorporation step causes spurious inference error
Summary: Multiple equality constraints on inference vars are not used to generate new inference constraints
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/lambda/TargetType28.out
+ test/tools/javac/lambda/TargetType67.java
+ test/tools/javac/lambda/TargetType68.java
+ test/tools/javac/lambda/TargetType69.java

Changeset: 5da12e8a59ba
Author:    mcimadamore
Date:      2013-03-22 12:44 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/5da12e8a59ba

8010387: Javac crashes when diagnostic mentions anonymous inner class' type variables
Summary: Rich formatter doesn't preprocess supertypes of an anonymous inner class
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
+ test/tools/javac/Diagnostics/8010387/T8010387.java
+ test/tools/javac/Diagnostics/8010387/T8010387.out

Changeset: f4500abff1fd
Author:    darcy
Date:      2013-03-22 10:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/f4500abff1fd

7080464: langtools regression test failures when assertions are enabled
Reviewed-by: jjg

! test/tools/javac/api/TestJavacTaskScanner.java
! test/tools/javac/diags/MessageFile.java
! test/tools/javac/diags/MessageInfo.java

Changeset: fdf30b225e1c
Author:    mfang
Date:      2013-03-25 16:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/fdf30b225e1c

8010521: jdk8 l10n resource file translation update 2
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties
! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties
! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties
! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties
! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties
! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties

Changeset: 65e1ca8dcdc7
Author:    mfang
Date:      2013-03-25 18:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/65e1ca8dcdc7

Merge


Changeset: 28e466e9cd34
Author:    lana
Date:      2013-03-26 12:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/28e466e9cd34

Merge

- src/share/classes/com/sun/tools/javac/Server.java
- src/share/classes/com/sun/tools/jdeps/resources/jdk.properties
- src/share/classes/javax/lang/model/type/AnnotatedType.java
- test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java

Changeset: cfb65ca92082
Author:    lana
Date:      2013-04-01 21:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/cfb65ca92082

Merge

- src/share/classes/com/sun/tools/javac/Server.java
- src/share/classes/com/sun/tools/jdeps/resources/jdk.properties
- src/share/classes/javax/lang/model/type/AnnotatedType.java
- test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java



From lana.steuck at oracle.com  Wed Apr  3 02:08:21 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 03 Apr 2013 02:08:21 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/hotspot: 87 new changesets
Message-ID: <20130403021213.DA6BB48571@hg.openjdk.java.net>

Changeset: 4f7380dca47e
Author:    katleman
Date:      2013-03-21 10:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/4f7380dca47e

Added tag jdk8-b82 for changeset 3db4ab0e12f4

! .hgtags

Changeset: 7ae04e71af90
Author:    amurillo
Date:      2013-03-15 11:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/7ae04e71af90

8010105: new hotspot build - hs25-b24
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 39432a1cefdd
Author:    minqi
Date:      2013-03-14 00:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/39432a1cefdd

8003348: SA can not read core file on OS
Summary: Macosx uses Mach-O file format for binary files, not ELF format. Currently SA works on core files on other platforms, t his change enables SA work on core file generated on Darwin.
Reviewed-by: sla, sspitsyn
Contributed-by: yumin.qi at oracle.com

! agent/src/os/bsd/MacosxDebuggerLocal.m
! agent/src/os/bsd/Makefile
! agent/src/os/bsd/libproc.h
! agent/src/os/bsd/libproc_impl.c
! agent/src/os/bsd/libproc_impl.h
! agent/src/os/bsd/ps_core.c
! agent/src/os/bsd/symtab.c
! agent/src/os/bsd/symtab.h
! agent/src/share/classes/sun/jvm/hotspot/BsdVtblAccess.java
! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java
! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java
! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java
! agent/src/share/native/sadis.c
! make/bsd/makefiles/saproc.make

Changeset: 1fc4d4768b90
Author:    coleenp
Date:      2013-03-15 17:24 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1fc4d4768b90

8007725: NPG: Klass::restore_unshareable_info() triggers assert(k->java_mirror() == NULL)
Summary: Check for exception during SystemDictionary::resolve_instance_class_or_null() and clean up.
Reviewed-by: coleenp, acorn, hseigel, minqi
Contributed-by: ioi.lam at oracle.com

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/method.cpp

Changeset: 82f49e8e2c28
Author:    zgu
Date:      2013-03-15 11:53 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/82f49e8e2c28

8009614: nsk/split_verifier/stress/ifelse/ifelse002_30 fails with 'assert((size & (granularity - 1)) == 0) failed: size not aligned to os::vm_allocation_granularity()
Summary: Align up vm allocation size to os defined granularity
Reviewed-by: dholmes, coleenp

! src/share/vm/memory/metaspace.cpp

Changeset: 919a5f9f36a9
Author:    zgu
Date:      2013-03-15 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/919a5f9f36a9

Merge


Changeset: 82ab039b9680
Author:    dcubed
Date:      2013-03-17 08:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/82ab039b9680

Merge

! src/share/vm/memory/metaspace.cpp

Changeset: 117bb0519114
Author:    sla
Date:      2013-03-19 13:41 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/117bb0519114

8009456: SA: typeToVtbl of BasicTypeDataBase should not be static
Reviewed-by: coleenp, sla
Contributed-by: yunda.mly at taobao.com

! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java

Changeset: 686916dc0439
Author:    sla
Date:      2013-03-19 13:44 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/686916dc0439

8009457: SA: A small fix on "scanoops" command in CLHSDB
Reviewed-by: sla, coleenp, kmo
Contributed-by: yunda.mly at taobao.com

! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java

Changeset: 9960dce2024f
Author:    kmo
Date:      2013-03-14 13:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/9960dce2024f

8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012
Summary: add cases for _MSC_VER == 1600 and 1700
Reviewed-by: zgu

! src/share/vm/runtime/vm_version.cpp

Changeset: a40807924950
Author:    kmo
Date:      2013-03-14 16:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a40807924950

Merge


Changeset: f3d486462d36
Author:    morris
Date:      2013-03-15 18:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/f3d486462d36

Merge


Changeset: 96ef09c26978
Author:    morris
Date:      2013-03-16 07:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/96ef09c26978

8009166: [parfait] Null pointer deference in hotspot/src/share/vm/opto/type.cpp
Summary: add guarantee() to as_instance_type()
Reviewed-by: kvn, twisti

! src/share/vm/opto/type.cpp

Changeset: 8b4ce9870fd6
Author:    morris
Date:      2013-03-16 07:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/8b4ce9870fd6

8009156: [parfait] Null pointer deference in hotspot/src/share/vm/services/memoryService.cpp
Summary: add guarantee() to add_generation_memory_pool()
Reviewed-by: kvn, twisti

! src/share/vm/services/memoryService.cpp

Changeset: 0a2deac0bbfb
Author:    morris
Date:      2013-03-16 07:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/0a2deac0bbfb

8008328: [partfait] Null pointer defererence in hotspot/src/cpu/x86/vm/frame_x86.inline.hpp
Summary: add guarantee() to oop_result inlines
Reviewed-by: kvn, twisti

! src/cpu/x86/vm/frame_x86.inline.hpp

Changeset: 9ef47379df20
Author:    morris
Date:      2013-03-16 07:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/9ef47379df20

8010144: [parfait] Null pointer deference in hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp
Summary: add null check to signal handler
Reviewed-by: dcubed

! src/os_cpu/linux_x86/vm/os_linux_x86.cpp

Changeset: 8552f0992748
Author:    kmo
Date:      2013-03-15 22:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/8552f0992748

8008796: SA: Oop.iterateFields() should support CompressedKlassPointers again
Summary: add a missing change from JDK-7054512 so that Oop.iterateFields() works with UseCompressedKlassPointers
Reviewed-by: coleenp, roland
Contributed-by: yunda.mly at taobao.com

! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java

Changeset: 592f9722c72e
Author:    kmo
Date:      2013-03-16 21:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/592f9722c72e

Merge


Changeset: 4efac99a998b
Author:    iignatyev
Date:      2013-03-18 04:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/4efac99a998b

8008211: Some of WB tests on compiler fail
Reviewed-by: kvn, vlivanov

! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java

Changeset: a5de0cc2f91c
Author:    roland
Date:      2013-03-18 13:19 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a5de0cc2f91c

8008555: Debugging code in compiled method sometimes leaks memory
Summary: support for strings that have same life-time as code that uses them.
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeBlob.hpp
! src/share/vm/code/icBuffer.hpp
! src/share/vm/code/stubs.cpp
! src/share/vm/code/stubs.hpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/compiler/disassembler.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreter.hpp
! src/share/vm/runtime/stubCodeGenerator.cpp

Changeset: 578d9044c463
Author:    roland
Date:      2013-03-18 09:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/578d9044c463

Merge


Changeset: be4d5c6c1f79
Author:    neliasso
Date:      2013-03-19 10:31 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/be4d5c6c1f79

8010121: Remove definition of ShouldNotReachHere2(msg)
Reviewed-by: kvn, stefank, rbackman, twisti
Contributed-by: niclas.adlertz at oracle.com

! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/oops/fieldInfo.hpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/debug.hpp

Changeset: f15df3af32c5
Author:    morris
Date:      2013-03-19 07:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/f15df3af32c5

8009172: [parfait] Null pointer deference in hotspot/src/share/vm/opto/output.cpp
Summary: add guarantee() to DoScheduling()
Reviewed-by: twisti, kvn

! src/share/vm/opto/output.cpp

Changeset: 75a28f465a12
Author:    morris
Date:      2013-03-19 07:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/75a28f465a12

8008663: [parfait] Null pointer deference in hotspot/src/share/vm/compiler/compileBroker.cpp
Summary: add NULL checks for compiler name
Reviewed-by: twisti, kvn

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp

Changeset: 80208f353616
Author:    kvn
Date:      2013-03-19 10:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/80208f353616

8010222: 8007439 disabled inlining of cold accessor methods
Summary: added missing parenthesis
Reviewed-by: jrose

! src/share/vm/opto/bytecodeInfo.cpp

Changeset: 2eef6d34833b
Author:    morris
Date:      2013-03-19 11:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/2eef6d34833b

8009022: [parfait] Null pointer deference in hotspot/src/share/vm/oops/generateOopMap.cpp
Summary: add guarantee() checks to merge_state_into_bb()
Reviewed-by: kvn

! src/share/vm/oops/generateOopMap.cpp

Changeset: 3b9368710f08
Author:    morris
Date:      2013-03-19 12:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3b9368710f08

8008811: [parfait] Null pointer deference in hotspot/src/share/vm/opto/loopopts.cpp
Summary: add guarantee() checks
Reviewed-by: kvn

! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/loopopts.cpp

Changeset: 1275835a4ccc
Author:    morris
Date:      2013-03-19 16:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1275835a4ccc

Merge


Changeset: 41340544e182
Author:    morris
Date:      2013-03-20 06:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/41340544e182

8009248: [parfait] Null pointer deference in hotspot/src/share/vm/code/compiledIC.cpp
Summary: add guarantee() to set_to_interpreted()
Reviewed-by: kvn

! src/share/vm/code/compiledIC.cpp

Changeset: 2dec1d9bfbe1
Author:    morris
Date:      2013-03-20 06:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/2dec1d9bfbe1

8009565: [partfait] Null pointer deference in hotspot/src/share/vm/ci/ciEnv.cpp
Summary: add guarantee() to get_instance_klass_for_declared_method_holder()
Reviewed-by: kvn

! src/share/vm/ci/ciEnv.cpp

Changeset: 653d0346aa80
Author:    morris
Date:      2013-03-20 06:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/653d0346aa80

8009578: [parfait] Null pointer deference in hotspot/src/share/vm/classfile/defaultMethods.cpp
Summary: add guarantee() to disqualify_method()
Reviewed-by: kvn

! src/share/vm/classfile/defaultMethods.cpp

Changeset: a59625d96f71
Author:    morris
Date:      2013-03-20 07:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a59625d96f71

8009181: [parfait] Null pointer deference in hotspot/src/share/vm/opto/loopTransform.cpp
Summary: add guarantee() to insert_pre_post_loops()
Reviewed-by: kvn

! src/share/vm/opto/loopTransform.cpp

Changeset: 98f3af397705
Author:    twisti
Date:      2013-03-20 17:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/98f3af397705

8006965: remove test_gamma and add dedicated test_* targets instead
Reviewed-by: kvn, jcoomes

! make/Makefile
! make/bsd/Makefile
! make/bsd/makefiles/buildtree.make
! make/defs.make
! make/linux/Makefile
! make/linux/makefiles/buildtree.make
! make/solaris/Makefile
! make/solaris/makefiles/buildtree.make
- make/test/Queens.java

Changeset: 589aa23334ea
Author:    morris
Date:      2013-03-21 10:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/589aa23334ea

8009584: [parfait] Null pointer deference in hotspot/src/cpu/x86/vm/relocInfo_x86.cpp
Summary: added guarantee() to pd_address_in_code()
Reviewed-by: kvn

! src/cpu/x86/vm/relocInfo_x86.cpp

Changeset: c3c64a973559
Author:    morris
Date:      2013-03-21 10:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/c3c64a973559

8009593: [parfait] Null pointer deference in hotspot/src/share/vm/oops/constantPool.cpp
Summary: added guarantee() to print_entry_on()
Reviewed-by: kvn

! src/share/vm/oops/constantPool.cpp

Changeset: 3536ea6bc4df
Author:    morris
Date:      2013-03-21 21:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3536ea6bc4df

Merge

- make/test/Queens.java

Changeset: 79af1312fc2c
Author:    mgerdin
Date:      2013-03-14 10:54 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/79af1312fc2c

8005602: NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used
Summary: Call purge() on CLDG after sweep(), reorder purge() call in GenCollectedHeap
Reviewed-by: jmasa, stefank

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/metaspace.cpp

Changeset: 3c226052f7dc
Author:    tschatzl
Date:      2013-03-14 09:37 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3c226052f7dc

6733980: par compact - TraceGen1Time always shows 0.0000 seconds
Summary: Use the correct collector to retrieve accumulated gen1 trace time
Reviewed-by: johnc, jmasa

! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp

Changeset: 19f9fabd94cc
Author:    stefank
Date:      2013-03-18 09:34 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/19f9fabd94cc

Merge

! src/share/vm/memory/metaspace.cpp

Changeset: fa08949fe0cb
Author:    johnc
Date:      2013-03-18 11:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/fa08949fe0cb

8009536: G1: Apache Lucene hang during reference processing
Summary: In CMTask::do_marking_step(), Skip offering termination and entering the first and second synchronization barriers if called from a serial context, i.e. the VM thread.
Reviewed-by: brutisso, tschatzl

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp

Changeset: e864cc14ca75
Author:    johnc
Date:      2013-03-19 00:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e864cc14ca75

8009940: G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809
Summary: Skip reference processing if the global marking stack overflows during remark. Refactor and rename set_phase(); move code that sets the concurrency level into its own routine. Do not call set_phase() from within parallel reference processing; use the concurrency level routine instead. The marking state should only set reset by CMTask[0] during the concurrent phase of the marking cycle; if an overflow occurs at any stage during the remark, the marking state will be reset after reference processing.
Reviewed-by: brutisso, jmasa

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp

Changeset: 1179172e9ec9
Author:    johnc
Date:      2013-03-19 09:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1179172e9ec9

8008301: G1: guarantee(satb_mq_set.completed_buffers_num() == 0) failure
Summary: If the marking stack overflows while the marking tasks are draining the SATB buffers, remark will exit with some SATB buffers left unprocessed. Relax the guarantee to allow for overflow.
Reviewed-by: jmasa, brutisso

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: 7f0cb32dd233
Author:    mgerdin
Date:      2013-03-21 09:07 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/7f0cb32dd233

8004241: NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option
Summary: Enforce MaxMetaspaceSize for both metaspace parts, check MaxMetaspaceSize against "reserved", not "capacity"
Reviewed-by: jmasa, johnc

! src/share/vm/memory/metaspace.cpp

Changeset: 47902e9acb3a
Author:    stefank
Date:      2013-03-22 10:32 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/47902e9acb3a

Merge

! src/share/vm/memory/metaspace.cpp

Changeset: 5855e849c7e6
Author:    stefank
Date:      2013-03-22 12:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/5855e849c7e6

Merge


Changeset: 499ccc15bbc8
Author:    bpittore
Date:      2013-03-15 15:20 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/499ccc15bbc8

8005716: Enhance JNI specification to allow support of static JNI libraries in Embedded JREs
Reviewed-by: dlong, alanb, mduigou

! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jni.h
! src/share/vm/runtime/thread.cpp

Changeset: 9e62e72c59cc
Author:    bobv
Date:      2013-03-17 06:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/9e62e72c59cc

Merge


Changeset: 3be6a41ad358
Author:    dholmes
Date:      2013-03-18 19:34 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3be6a41ad358

8008783: Modifications needed to JPRT to allow for building hard float abi and new bundle changes
Reviewed-by: twisti, collins, bobv, jwilhelm

! make/jprt.properties

Changeset: 804663118c1f
Author:    jprovino
Date:      2013-03-22 10:09 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/804663118c1f

Merge


Changeset: aca25026e2a4
Author:    vladidan
Date:      2013-03-22 17:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/aca25026e2a4

Merge


Changeset: e3a41fc02348
Author:    amurillo
Date:      2013-03-23 01:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e3a41fc02348

Merge

- make/test/Queens.java

Changeset: 1c8db54ee9f3
Author:    amurillo
Date:      2013-03-23 01:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1c8db54ee9f3

Added tag hs25-b24 for changeset e3a41fc02348

! .hgtags

Changeset: e614fc564ded
Author:    katleman
Date:      2013-03-28 10:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e614fc564ded

Added tag jdk8-b83 for changeset 1c8db54ee9f3

! .hgtags

Changeset: 59a41e1357ab
Author:    amurillo
Date:      2013-03-23 10:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/59a41e1357ab

8010498: new hotspot build - hs25-b25
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: eca90b8a06eb
Author:    rdurbin
Date:      2013-03-19 11:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/eca90b8a06eb

7030610: runtime/6878713/Test6878713.sh fails Error. failed to clean up files after test
7123945: runtime/6878713/Test6878713.sh require about 2G of native memory, swaps and times out
Summary: Add new diagnostic option -XX:MallocMaxTestWords=NNN and fix Test6878713.sh.
Reviewed-by: dcubed, coleenp, dholmes, iklam

! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.cpp
! test/runtime/6878713/Test6878713.sh

Changeset: a649f6511c04
Author:    ctornqvi
Date:      2013-03-20 08:17 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a649f6511c04

8010084: Race in runtime/NMT/BaselineWithParameter.java
Summary: Added a waitFor() on the process
Reviewed-by: mgerdin, sla, zgu

! test/runtime/NMT/BaselineWithParameter.java

Changeset: 91bf0bdae37b
Author:    coleenp
Date:      2013-03-20 08:04 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/91bf0bdae37b

8008217: CDS: Class data sharing limits the malloc heap on Solaris
Summary: In 64bit VM move CDS archive address to 32G on all platforms using new flag SharedBaseAddress.  In 32bit VM set CDS archive address to 3Gb on Linux and let other OSs pick the address.
Reviewed-by: kvn, dcubed, zgu, hseigel

! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp
! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp
! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp
! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp
! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp
! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp
! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp
! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 2c7663baeb67
Author:    acorn
Date:      2013-03-20 11:43 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/2c7663baeb67

8010017: lambda: reflection get(Declared)Methods support for default methods.
Summary: Don't expose vm generated overpass (bridges to default methods).
Reviewed-by: dholmes, fparain

! src/share/vm/prims/jvm.cpp

Changeset: 79259e97a072
Author:    acorn
Date:      2013-03-20 12:20 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/79259e97a072

Merge


Changeset: 1feda2e9f044
Author:    ctornqvi
Date:      2013-03-20 20:40 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1feda2e9f044

8007982: some runtime/CommandLine/ tests fail on 32-bit platforms
Summary: Changed tests to use platform independent flags
Reviewed-by: collins, hseigel, zgu

! test/runtime/CommandLine/BooleanFlagWithInvalidValue.java
! test/runtime/CommandLine/FlagWithInvalidValue.java
! test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java

Changeset: 81d1b58c078f
Author:    rdurbin
Date:      2013-03-20 20:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/81d1b58c078f

8010396: checking MallocMaxTestWords in testMalloc() function is redundant
Summary: Remove redundant checks in testMalloc and add assert.
Reviewed-by: dcubed, coleenp, dholmes

! src/share/vm/runtime/os.cpp

Changeset: e7081eb7e786
Author:    dcubed
Date:      2013-03-20 20:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e7081eb7e786

Merge


Changeset: 06db4c0afbf3
Author:    zgu
Date:      2013-03-20 09:42 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/06db4c0afbf3

8009298: NMT: Special version of class loading/unloading with runThese stresses out NMT
8009777: NMT: add new NMT dcmd to control auto shutdown option
Summary: Added diagnostic VM option and DCmd command to allow NMT stay alive under stress situation
Reviewed-by: dcubed, coleenp

! src/share/vm/runtime/globals.hpp
! src/share/vm/services/memTracker.cpp
! src/share/vm/services/memTracker.hpp
! src/share/vm/services/nmtDCmd.cpp
! src/share/vm/services/nmtDCmd.hpp

Changeset: 0ac03fef364f
Author:    zgu
Date:      2013-03-21 06:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/0ac03fef364f

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 14509df4cd63
Author:    iklam
Date:      2013-03-21 20:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/14509df4cd63

8010389: After fix for 7107135 a failed dlopen() call results in a VM crash
Summary: Call dlerror() in VM thread as necessary.
Reviewed-by: coleenp, dholmes

! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
+ test/runtime/8010389/VMThreadDlopen.java

Changeset: 6574f999e0cf
Author:    dcubed
Date:      2013-03-23 22:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/6574f999e0cf

Merge

! src/share/vm/memory/metaspace.cpp

Changeset: c342fbdf8a70
Author:    ctornqvi
Date:      2013-03-24 09:11 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/c342fbdf8a70

8008454: test/runtime/NMT/PrintNMTStatistics is broken
Summary: Added @run tag so that it actually runs the test, also fixed broken command line and incorrect parsing. Also reviewed by gerard.ziemski at oracle.com
Reviewed-by: mgerdin, zgu

! test/runtime/NMT/PrintNMTStatistics.java

Changeset: 9c8e53c7bed0
Author:    ctornqvi
Date:      2013-03-24 09:21 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/9c8e53c7bed0

Merge

- make/test/Queens.java

Changeset: 729be16a470b
Author:    hseigel
Date:      2013-03-25 08:37 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/729be16a470b

8010667: Non-zero padding is not allowed in splitverifier for tableswitch/lookupswitch instructions.
Summary: Don't check the padding bits if class file version is >= 51.
Reviewed-by: kvn, dholmes, coleenp

! src/share/vm/classfile/verifier.cpp

Changeset: b8deb3205b51
Author:    bharadwaj
Date:      2013-03-25 09:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b8deb3205b51

8009552: test/vm/verifier/TestStaticIF.java failing with hs25.0-b
Summary: Remove support for verification of class files with version 52 and above from type inference verifier.
Reviewed-by: acorn, hseigel

! src/share/vm/classfile/verifier.cpp
- test/runtime/8007736/TestStaticIF.java

Changeset: 1916ca1dec2f
Author:    rbackman
Date:      2013-03-26 15:00 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1916ca1dec2f

8009382: Add JVM_Get{Field|Method}TypeAnnotations
Reviewed-by: dcubed, rbackman
Contributed-by: Joel Borggren-Franck 

! make/bsd/makefiles/mapfile-vers-debug
! make/bsd/makefiles/mapfile-vers-product
! make/linux/makefiles/mapfile-vers-debug
! make/linux/makefiles/mapfile-vers-product
! make/solaris/makefiles/mapfile-vers
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h

Changeset: 36376b540a98
Author:    hseigel
Date:      2013-03-26 09:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/36376b540a98

8009595: The UseSplitVerifier option needs to be deprecated.
Summary: Put UseSplitVerifier option on the deprecated list.
Reviewed-by: dcubed, kmo, acorn

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: a8016373a893
Author:    hseigel
Date:      2013-03-26 12:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a8016373a893

Merge


Changeset: 6b748c9e1845
Author:    zgu
Date:      2013-03-26 14:11 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/6b748c9e1845

8010651: create.bat still builds the kernel
Summary: Remove old kernel build targets and VS C++ projects created by create.bat on Windows
Reviewed-by: coleenp, sla

! make/windows/build.make
! make/windows/create.bat
! make/windows/makefiles/compile.make
! make/windows/makefiles/product.make
! make/windows/makefiles/vm.make
- make/windows/projectfiles/kernel/Makefile
- make/windows/projectfiles/kernel/vm.def
- make/windows/projectfiles/kernel/vm.dsw
! src/share/tools/ProjectCreator/BuildConfig.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java

Changeset: 85192022ba8c
Author:    zgu
Date:      2013-03-26 11:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/85192022ba8c

Merge

- test/runtime/8007736/TestStaticIF.java

Changeset: 23f2d309e855
Author:    zgu
Date:      2013-03-26 15:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/23f2d309e855

Merge

- make/windows/projectfiles/kernel/Makefile
- make/windows/projectfiles/kernel/vm.def
- make/windows/projectfiles/kernel/vm.dsw

Changeset: 7f16d1812865
Author:    tamao
Date:      2013-03-20 12:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/7f16d1812865

7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp
Summary: Remove the related assertions becasue they do not hold here.
Reviewed-by: jmasa, tschatzl
Contributed-by: tamao 

! src/share/vm/runtime/arguments.cpp

Changeset: dbd5837b342f
Author:    ehelin
Date:      2013-03-22 16:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/dbd5837b342f

8000754: NPG: Implement a MemoryPool MXBean for Metaspace
Reviewed-by: jmasa, stefank

! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/services/memoryManager.cpp
! src/share/vm/services/memoryManager.hpp
! src/share/vm/services/memoryPool.cpp
! src/share/vm/services/memoryPool.hpp
! src/share/vm/services/memoryService.cpp
! src/share/vm/services/memoryService.hpp
+ test/gc/metaspace/TestMetaspaceMemoryPools.java

Changeset: 338b3a9e29b5
Author:    stefank
Date:      2013-03-25 11:00 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/338b3a9e29b5

Merge

! src/share/vm/services/memoryService.cpp

Changeset: 42e370795a39
Author:    ehelin
Date:      2013-03-27 10:55 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/42e370795a39

8010818: NPG: Remove metaspace memory pools
Reviewed-by: mgerdin, stefank

! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/services/memoryManager.cpp
! src/share/vm/services/memoryManager.hpp
! src/share/vm/services/memoryPool.cpp
! src/share/vm/services/memoryPool.hpp
! src/share/vm/services/memoryService.cpp
! src/share/vm/services/memoryService.hpp
- test/gc/metaspace/TestMetaspaceMemoryPools.java

Changeset: aeb22fdaa14c
Author:    brutisso
Date:      2013-03-28 09:07 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/aeb22fdaa14c

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: 728b89404e34
Author:    jprovino
Date:      2013-03-21 10:18 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/728b89404e34

8009904: jvmtiClassFileReconstituter.cpp needs to be excluded from the minimal jvm
Summary: jvmtiClassFileReconstituter.cpp needs to be added to the list of files to exclude when JVMTI is excluded from the jvm
Reviewed-by: dholmes, sspitsyn

! make/excludeSrc.make

Changeset: 7ca101eef24a
Author:    jprovino
Date:      2013-03-23 14:59 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/7ca101eef24a

Merge


Changeset: 04d6d4322c6a
Author:    collins
Date:      2013-03-27 09:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/04d6d4322c6a

8009152: A number of jtreg tests need review/improvement
Summary: Added a new test_env.txt file to capture common shell variable. Added concept of COMPILEJAVA for use when TESTJAVA is a JRE. If COMPILEJAVA not set then TESTJAVA will be the default with assumption it is a JDK.
Reviewed-by: kvn, brutisso, coleenp

! test/compiler/5091921/Test6890943.sh
! test/compiler/5091921/Test7005594.sh
! test/compiler/6857159/Test6857159.sh
! test/compiler/7068051/Test7068051.sh
! test/compiler/7070134/Test7070134.sh
! test/compiler/7200264/Test7200264.sh
! test/gc/6941923/test6941923.sh
! test/runtime/6626217/Test6626217.sh
! test/runtime/6878713/Test6878713.sh
! test/runtime/6929067/Test6929067.sh
! test/runtime/7020373/Test7020373.sh
! test/runtime/7051189/Xchecksig.sh
! test/runtime/7107135/Test7107135.sh
! test/runtime/7110720/Test7110720.sh
! test/runtime/7158804/Test7158804.sh
! test/runtime/7162488/Test7162488.sh
+ test/test_env.sh

Changeset: d1897e7e0488
Author:    collins
Date:      2013-03-28 15:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/d1897e7e0488

Merge

! test/runtime/6878713/Test6878713.sh

Changeset: 8d0f263a370c
Author:    amurillo
Date:      2013-03-28 19:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/8d0f263a370c

Merge

- make/windows/projectfiles/kernel/Makefile
- make/windows/projectfiles/kernel/vm.def
- make/windows/projectfiles/kernel/vm.dsw
- test/runtime/8007736/TestStaticIF.java

Changeset: af788b85010e
Author:    amurillo
Date:      2013-03-28 19:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/af788b85010e

Added tag hs25-b25 for changeset 8d0f263a370c

! .hgtags



From lana.steuck at oracle.com  Wed Apr  3 02:11:06 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 03 Apr 2013 02:11:06 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 54 new changesets
Message-ID: <20130403022408.D35CC48572@hg.openjdk.java.net>

Changeset: 624bcb480006
Author:    omajid
Date:      2013-03-18 10:46 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/624bcb480006

8010030: Allow configure to detect if EC implementation is present
Reviewed-by: andrew, dholmes

! makefiles/CompileNativeLibraries.gmk

Changeset: cdcd4512c6f1
Author:    katleman
Date:      2013-03-21 10:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/cdcd4512c6f1

Added tag jdk8-b82 for changeset 624bcb480006

! .hgtags

Changeset: 6782f2c46bca
Author:    wetmore
Date:      2013-03-21 16:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6782f2c46bca

8009517: new code changes causing errors in old build (-Werror) environment
Reviewed-by: mduigou

! make/com/sun/org/apache/xml/Makefile
! make/javax/others/Makefile

Changeset: ac519af51769
Author:    dcherepanov
Date:      2013-03-27 08:32 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ac519af51769

Merge


Changeset: 8cc500af2454
Author:    katleman
Date:      2013-03-28 10:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/8cc500af2454

Added tag jdk8-b83 for changeset ac519af51769

! .hgtags

Changeset: 07acfb90700b
Author:    malenkov
Date:      2013-03-14 12:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/07acfb90700b

8000183: 7163696: JCK Swing interactive test JScrollBarTest0013 fails with Nimbus and GTK L&Fs
Reviewed-by: alexsch, serb

! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java
+ test/javax/swing/JScrollBar/7163696/Test7163696.java

Changeset: d4e1c5803a59
Author:    alexsch
Date:      2013-03-15 17:02 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d4e1c5803a59

8009221: [macosx] Two closed/javax/swing regression tests fail on MacOSX.
Reviewed-by: serb, alexp

+ test/javax/swing/JMenu/4515762/bug4515762.java
+ test/javax/swing/JRootPane/4670486/bug4670486.java
! test/javax/swing/regtesthelpers/Util.java

Changeset: 2725b8a783e7
Author:    lana
Date:      2013-03-15 16:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/2725b8a783e7

Merge

- make/tools/javazic/Makefile
- make/tools/src/build/tools/javazic/BackEnd.java
- make/tools/src/build/tools/javazic/Checksum.java
- make/tools/src/build/tools/javazic/DayOfWeek.java
- make/tools/src/build/tools/javazic/Gen.java
- make/tools/src/build/tools/javazic/GenDoc.java
- make/tools/src/build/tools/javazic/Main.java
- make/tools/src/build/tools/javazic/Mappings.java
- make/tools/src/build/tools/javazic/Month.java
- make/tools/src/build/tools/javazic/Rule.java
- make/tools/src/build/tools/javazic/RuleDay.java
- make/tools/src/build/tools/javazic/RuleRec.java
- make/tools/src/build/tools/javazic/Simple.java
- make/tools/src/build/tools/javazic/Time.java
- make/tools/src/build/tools/javazic/Timezone.java
- make/tools/src/build/tools/javazic/Zone.java
- make/tools/src/build/tools/javazic/ZoneRec.java
- make/tools/src/build/tools/javazic/Zoneinfo.java
- src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java
- src/share/classes/java/util/function/Block.java
- src/share/classes/java/util/function/DoubleBlock.java
- src/share/classes/java/util/function/IntBlock.java
- src/share/classes/java/util/function/LongBlock.java
- src/share/classes/sun/security/util/KeyLength.java
- test/javax/script/RhinoExceptionTest.java

Changeset: 4bf5a5a72664
Author:    serb
Date:      2013-03-18 22:10 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4bf5a5a72664

8000435: [macosx] Button painting error under Java 7 on Mac
Reviewed-by: denis, alexsch

! src/macosx/classes/com/apple/laf/AquaButtonBorder.java
! src/macosx/classes/com/apple/laf/AquaButtonExtendedTypes.java

Changeset: af6049edac00
Author:    kshefov
Date:      2013-03-19 17:51 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/af6049edac00

8009881: TEST_BUG: javax/swing/JTree/8004298/bug8004298.java should be modified
Reviewed-by: serb, alexsch

! test/javax/swing/JTree/8004298/bug8004298.java

Changeset: 4e15c3e56315
Author:    kshefov
Date:      2013-03-20 14:02 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4e15c3e56315

8009880: TEST_BUG: Test java/beans/Introspector/TestTypeResolver.java should be modified again
Reviewed-by: malenkov, alexsch

! test/java/beans/Introspector/TestTypeResolver.java

Changeset: 87001c7bb678
Author:    alitvinov
Date:      2013-03-20 20:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/87001c7bb678

6550588: java.awt.Desktop cannot open file with Windows UNC filename
Reviewed-by: art, uta

! src/windows/classes/sun/awt/windows/WDesktopPeer.java
! src/windows/native/sun/windows/awt_Desktop.cpp
+ test/java/awt/Desktop/OpenByUNCPathNameTest/OpenByUNCPathNameTest.java

Changeset: ef948ef2b58f
Author:    alexsch
Date:      2013-03-21 16:50 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ef948ef2b58f

8007146: [macosx] Setting a display mode crashes JDK under VNC
Reviewed-by: serb

! src/macosx/native/sun/awt/CGraphicsDevice.m
+ test/java/awt/GraphicsDevice/CheckDisplayModes.java

Changeset: a275acd8bcae
Author:    denis
Date:      2013-03-22 19:56 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a275acd8bcae

7123476: DesktopOpenTests:When enter the file path and click the open button,it crash
Reviewed-by: art, anthony

! make/sun/xawt/FILES_c_unix.gmk
! makefiles/CompileNativeLibraries.gmk
! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h
! src/solaris/native/sun/xawt/awt_Desktop.c
+ src/solaris/native/sun/xawt/gnome_interface.c
+ src/solaris/native/sun/xawt/gnome_interface.h

Changeset: 15a2599f470f
Author:    lana
Date:      2013-03-26 11:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/15a2599f470f

Merge

! makefiles/CompileNativeLibraries.gmk

Changeset: e497a050e059
Author:    uta
Date:      2013-03-13 13:22 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e497a050e059

7190897: (fs) Files.isWritable method returns false when the path is writable (win)
Summary: The [GetEffectiveRightsFromAcl] based implementation was changed to the [AccessCheck] based.
Reviewed-by: alanb

! src/windows/classes/sun/nio/fs/WindowsConstants.java
! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java
! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java
! src/windows/classes/sun/nio/fs/WindowsSecurity.java
! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c

Changeset: e33cbbe21419
Author:    alanb
Date:      2013-03-13 17:58 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e33cbbe21419

8009751: (se) Selector spin when select, close and interestOps(0) invoked at same time (lnx)
Reviewed-by: zhouyx, chegar, robm

! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java

Changeset: 94335b6ffb32
Author:    jgish
Date:      2013-03-13 11:24 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/94335b6ffb32

8002070: Remove the stack search for a resource bundle for Logger to use
Summary: The fragile, vulnerable, stack crawling has been eliminated from findResourceBundle(String)
Reviewed-by: mchung, alanb

! src/share/classes/java/util/logging/Logger.java
! test/java/util/logging/LoggerResourceBundleRace.java

Changeset: ef0c60b93a17
Author:    dxu
Date:      2013-03-13 14:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ef0c60b93a17

8001334: Remove use of JVM_* functions from java.io code
Summary: Replace JVM_* functions with direct system calls in java io area
Reviewed-by: alanb, uta, martin

! make/java/nio/Makefile
! makefiles/CompileNativeLibraries.gmk
! src/share/native/java/io/ObjectOutputStream.c
! src/share/native/java/io/io_util.c
! src/share/native/java/io/io_util.h
! src/solaris/native/common/jdk_util_md.h
! src/solaris/native/java/io/FileDescriptor_md.c
! src/solaris/native/java/io/UnixFileSystem_md.c
! src/solaris/native/java/io/io_util_md.c
! src/solaris/native/java/io/io_util_md.h
! src/windows/native/common/jdk_util_md.h
! src/windows/native/java/io/io_util_md.c
! src/windows/native/java/io/io_util_md.h

Changeset: f5c85c0a9af0
Author:    robm
Date:      2013-03-14 00:21 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f5c85c0a9af0

8009650: HttpClient available() check throws SocketException when connection has been closed
Reviewed-by: chegar, khazra, dsamersoff
Contributed-by: sdouglas at redhat.com

! src/share/classes/sun/net/www/http/HttpClient.java
+ test/sun/net/www/http/HttpClient/IsAvailable.java

Changeset: 41289b4a1819
Author:    dholmes
Date:      2013-03-14 01:47 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/41289b4a1819

8009429: Miscellaneous profiles cleanup
8009428: Revert changes to $ substitution performed as part of nashorn integration
Reviewed-by: alanb, erikj

! makefiles/CreateJars.gmk
! makefiles/ProfileNames.gmk
! makefiles/Profiles.gmk
! makefiles/profile-includes.txt
! makefiles/profile-rtjar-includes.txt

Changeset: f010eb1e696f
Author:    alanb
Date:      2013-03-14 16:03 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f010eb1e696f

8005716: Enhance JNI specification to allow support of static JNI libraries in Embedded JREs
Reviewed-by: dlong, alanb, mduigou
Contributed-by: bill.pittore at oracle.com, bob.vandette at oracle.com

! make/java/java/mapfile-vers
! makefiles/mapfiles/libjava/mapfile-vers
! src/share/classes/java/lang/ClassLoader.java
! src/share/classes/java/lang/Runtime.java
! src/share/classes/java/lang/System.java
! src/share/javavm/export/jni.h
! src/share/native/common/jni_util.h
! src/share/native/java/lang/ClassLoader.c
! src/solaris/native/common/jni_util_md.c
! src/windows/native/common/jni_util_md.c

Changeset: ca9469a15792
Author:    alanb
Date:      2013-03-14 16:59 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ca9469a15792

7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1)
Reviewed-by: alanb, chegar
Contributed-by: yiming.wang at oracle.com

! test/java/nio/channels/DatagramChannel/Connect.java
! test/java/nio/channels/DatagramChannel/ConnectedSend.java
! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java
! test/javax/management/remote/mandatory/connection/RMIConnectionIdTest.java

Changeset: d79503c4c56f
Author:    naoto
Date:      2013-03-14 11:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d79503c4c56f

8008576: Calendar mismatch using Host LocaleProviderAdapter
Reviewed-by: okutsu

! make/java/java/FILES_java.gmk
! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/sun/util/locale/LanguageTag.java
! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java
+ src/share/classes/sun/util/locale/provider/CalendarProviderImpl.java
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
+ src/share/classes/sun/util/spi/CalendarProvider.java
! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c

Changeset: 46ad8dfabd5f
Author:    sundar
Date:      2013-03-15 19:30 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/46ad8dfabd5f

8010136: Make jrunscript's init.js to work on nashorn
Reviewed-by: lagergren, hannesw

! src/share/classes/com/sun/tools/script/shell/init.js

Changeset: c1a142965db0
Author:    lana
Date:      2013-03-15 23:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c1a142965db0

Merge

! makefiles/CompileNativeLibraries.gmk
! src/share/classes/java/util/logging/Logger.java
- src/share/classes/sun/security/util/KeyLength.java

Changeset: c1165d566a23
Author:    vlivanov
Date:      2013-03-06 16:59 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c1165d566a23

8009222: java.lang.IllegalArgumentException: not invocable, no method type when attempting to get getter method handle for a static field
Reviewed-by: jrose, twisti

! src/share/classes/java/lang/invoke/DirectMethodHandle.java
+ test/java/lang/invoke/8009222/Test8009222.java

Changeset: ec8229b26dbc
Author:    chegar
Date:      2013-03-17 09:55 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ec8229b26dbc

8010142: ProblemList.txt updates (3/2013)
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: a0275a47fa78
Author:    sla
Date:      2013-03-19 09:53 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a0275a47fa78

8006637: Failure to filter out native frame events on Solaris
Summary: Test is confused by other threads calling String.intern(). Add a thread filter to avoid this.
Reviewed-by: sspitsyn, alanb

! test/com/sun/jdi/NativeInstanceFilter.java

Changeset: e766da5575fa
Author:    dholmes
Date:      2013-03-19 06:01 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e766da5575fa

8009426: "profiles" target fails due to nashorn if "images" is not built first
Reviewed-by: alanb

! makefiles/CreateJars.gmk
! makefiles/Profiles.gmk
! makefiles/profile-includes.txt

Changeset: 4103eb6b2137
Author:    jzavgren
Date:      2013-03-18 14:21 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4103eb6b2137

8007607: security native code doesn't always use malloc, realloc, and calloc correctly
Reviewed-by: chegar, dsamersoff, valeriep

! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c
! src/share/native/sun/security/jgss/wrapper/NativeUtil.c
! src/solaris/native/com/sun/security/auth/module/Solaris.c
! src/solaris/native/com/sun/security/auth/module/Unix.c
! src/solaris/native/sun/security/smartcardio/pcsc_md.c

Changeset: 2241a2d34085
Author:    mduigou
Date:      2013-03-19 16:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/2241a2d34085

8001642: Add Optional, OptionalDouble, OptionalInt, OptionalLong
Reviewed-by: mduigou, darcy, alanb, jjb
Contributed-by: Brian Goetz 

+ src/share/classes/java/util/Optional.java
+ src/share/classes/java/util/OptionalDouble.java
+ src/share/classes/java/util/OptionalInt.java
+ src/share/classes/java/util/OptionalLong.java
+ test/java/util/Optional/Basic.java
+ test/java/util/Optional/BasicDouble.java
+ test/java/util/Optional/BasicInt.java
+ test/java/util/Optional/BasicLong.java

Changeset: fb23896a01f5
Author:    uta
Date:      2013-03-20 13:21 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/fb23896a01f5

8006193: (process) Clean-up java.lang.ProcessImpl.finalize, does not need to be public
Reviewed-by: alanb

! src/windows/classes/java/lang/ProcessImpl.java

Changeset: 3070b7363853
Author:    chegar
Date:      2013-03-20 14:39 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3070b7363853

8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe
Reviewed-by: khazra, alanb

! src/share/classes/sun/net/www/protocol/jar/JarURLConnection.java
! src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java
! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java

Changeset: 38116bfe5323
Author:    mullan
Date:      2013-03-20 10:58 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/38116bfe5323

8010112: NullPointerException in sun.security.provider.certpath.CertId()
Reviewed-by: vinnie

! src/share/classes/sun/security/provider/certpath/CertId.java
! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/share/classes/sun/security/x509/X509CertImpl.java

Changeset: 9859856920ed
Author:    mullan
Date:      2013-03-20 11:23 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9859856920ed

Merge

- src/share/classes/sun/security/util/KeyLength.java

Changeset: 38c1d0c2d6a6
Author:    mullan
Date:      2013-03-20 12:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/38c1d0c2d6a6

Merge


Changeset: ccd9f53377c4
Author:    mchung
Date:      2013-03-20 09:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ccd9f53377c4

8006104: Improve tests to test ".useParentHandlers" property set in the logging configuration
Reviewed-by: alanb

! test/java/util/logging/CustomLogManager.java
! test/java/util/logging/CustomLogManagerTest.java

Changeset: cf0049037deb
Author:    darcy
Date:      2013-03-20 15:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/cf0049037deb

8010427: Refine Method.isDefault implementation
Reviewed-by: acorn, dlsmith

! src/share/classes/java/lang/reflect/Method.java

Changeset: 3c1a4966d901
Author:    dholmes
Date:      2013-03-20 22:39 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3c1a4966d901

8006818: SunEC and SunPKCS11 providers should be in all profiles
Reviewed-by: dholmes, alanb, valeriep
Contributed-by: Jen Dority 

! makefiles/profile-includes.txt

Changeset: 9ee1aff76498
Author:    sundar
Date:      2013-03-21 19:19 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9ee1aff76498

8009869: Need to modify java.security property package.access to include nashorn packages
Reviewed-by: ahgross, jlaskey, lagergren

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 3f8fbb0ab155
Author:    robm
Date:      2013-03-21 17:33 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3f8fbb0ab155

8009251: Add proxy handling and keep-alive fixes to jsse
Reviewed-by: chegar

! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java
! src/share/classes/sun/net/www/protocol/https/HttpsClient.java

Changeset: 93cd7052d306
Author:    weijun
Date:      2013-03-22 19:59 +0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/93cd7052d306

8010531: Add BadKdc* tests to problem list for solaris-sparcv9
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: 470232a8e89d
Author:    stefank
Date:      2013-03-22 15:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/470232a8e89d

8005116: NPG: Rename -permstat option for jmap in jdk8 to -clstats
Reviewed-by: jmasa, sla
Contributed-by: Erik Helin 

! src/share/classes/sun/tools/jmap/JMap.java

Changeset: 518d6087e01f
Author:    stefank
Date:      2013-03-22 15:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/518d6087e01f

8004172: Update jstat counter names to reflect metaspace changes
Reviewed-by: mchung
Contributed-by: Erik Helin 

! src/share/classes/sun/tools/jstat/resources/jstat_options
! test/sun/tools/jstat/gcCapacityOutput1.awk
! test/sun/tools/jstat/gcCauseOutput1.awk
+ test/sun/tools/jstat/gcMetaCapacityOutput1.awk
! test/sun/tools/jstat/gcOldOutput1.awk
! test/sun/tools/jstat/gcOutput1.awk
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
+ test/sun/tools/jstat/jstatGcMetaCapacityOutput1.sh
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh
! test/sun/tools/jstat/lineCounts1.awk
! test/sun/tools/jstat/lineCounts2.awk
! test/sun/tools/jstat/lineCounts3.awk
! test/sun/tools/jstat/lineCounts4.awk
! test/sun/tools/jstat/options1.out
! test/sun/tools/jstat/options2.out
! test/sun/tools/jstat/timeStamp1.awk
! test/sun/tools/jstatd/jstatGcutilOutput1.awk

Changeset: 3470101fae58
Author:    weijun
Date:      2013-03-23 11:49 +0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3470101fae58

8009970: Several LoginModule classes need extra permission to load AuthResources
Reviewed-by: mullan

! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java
! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java
! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java

Changeset: ed63cace1d30
Author:    weijun
Date:      2013-03-23 11:49 +0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ed63cace1d30

8009875: Provide a default udp_preference_limit for krb5.conf
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/KdcComm.java
! src/share/classes/sun/security/krb5/internal/Krb5.java
! test/sun/security/krb5/auto/KDC.java
+ test/sun/security/krb5/config/DefUdpLimit.java

Changeset: d92a96dcbfe1
Author:    sundar
Date:      2013-03-25 19:25 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d92a96dcbfe1

8010704: The test closed/java/lang/SecurityManager/CheckPackageDefinition.java failed after fix for 8009869
Reviewed-by: lagergren, hannesw

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-solaris

Changeset: 5d0c891264bf
Author:    chegar
Date:      2013-03-25 14:29 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5d0c891264bf

8010668: builtin JNI libraries should not be unloaded
Reviewed-by: chegar, alanb
Contributed-by: Bill Pittore 

! src/share/native/java/lang/ClassLoader.c

Changeset: 5e383a73386a
Author:    mchung
Date:      2013-03-25 17:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5e383a73386a

8007703: Remove com.sun.servicetag API
Reviewed-by: dholmes, alanb, erikj

! make/com/sun/Makefile
! make/common/Release.gmk
! makefiles/CopyFiles.gmk
! makefiles/CopyIntoClasses.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcProperties.gmk
! makefiles/profile-includes.txt
! makefiles/profile-rtjar-includes.txt
! test/Makefile

Changeset: 335d2156222e
Author:    mchung
Date:      2013-03-25 18:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/335d2156222e

8010787: changeset for 8007703 is missing the deleted files
Reviewed-by: dholmes, alanb, erikj

- make/com/sun/servicetag/Makefile
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties

Changeset: 543d0fbc962e
Author:    lana
Date:      2013-03-26 12:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/543d0fbc962e

Merge

- make/com/sun/servicetag/Makefile
! makefiles/CompileNativeLibraries.gmk
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh

Changeset: ea7d0f49e5dd
Author:    lana
Date:      2013-04-01 21:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ea7d0f49e5dd

Merge

- make/com/sun/servicetag/Makefile
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh

Changeset: 9d4f539e36b6
Author:    lana
Date:      2013-04-02 17:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9d4f539e36b6

Merge

- make/com/sun/servicetag/Makefile
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh



From andrea.aime at geo-solutions.it  Wed Apr  3 08:09:25 2013
From: andrea.aime at geo-solutions.it (Andrea Aime)
Date: Wed, 3 Apr 2013 10:09:25 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
	<5154ACCD.5090105@oracle.com>
	
	
	
	
	
	
Message-ID: 

On Mon, Apr 1, 2013 at 11:20 PM, Laurent Bourg?s
wrote:

> Andra & Jim,
>
> Here is the current status of my patch alpha version:
> http://jmmc.fr/~bourgesl/share/java2d-pisces/
>
> There is still a lot to be done: clean-up, stats, pisces class instance
> recycling (renderer, stroker ...) and of course sizing correctly initial
> arrays (dirty or clean) in the RendererContext (thread local storage).
> For performance reasons, I am using now RendererContext members first
> (cache for rowAARLE for example) before using ArrayCaches (dynamic arrays).
>

Thank you Laurent, those are some nice speedups.
About the thread local storage, that is a sensible choice for highly
concurrent systems, at the same time, web containers normally complain about
orphaned thread locals created by an application and not cleaned up.
Not sure if ones created at the core libs level get special treatment, but
in general, I guess it would be nice to have some way to clean them up.

I'm not familiar with the API, but is there any way to clean them up when
the graphics2d gets disposed of?
A web application has no guarantee to see the same thread ever again during
his life, so thread locals have to be cleaned right away.

Either that, or see if there is any way to store the array caches in a
global structure backed by a concurrent collection to reduce/eliminate
contention.

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bourges.laurent at gmail.com  Wed Apr  3 09:01:22 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Wed, 3 Apr 2013 11:01:22 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
	<5154ACCD.5090105@oracle.com>
	
	
	
	
	
	
	
Message-ID: 

Thanks for your valueable feedback!

Here is the current status of my patch alpha version:
>> http://jmmc.fr/~bourgesl/share/java2d-pisces/
>>
>> There is still a lot to be done: clean-up, stats, pisces class instance
>> recycling (renderer, stroker ...) and of course sizing correctly initial
>> arrays (dirty or clean) in the RendererContext (thread local storage).
>> For performance reasons, I am using now RendererContext members first
>> (cache for rowAARLE for example) before using ArrayCaches (dynamic arrays).
>>
>
> Thank you Laurent, those are some nice speedups.
>
I think it can still be improved: I hope to make it as fast as ductus or
maybe more (I have several idea for aggressive optimizations) but the main
improvement consist in reusing memory (like C / C++ does) to avoid wasted
memory / GC overhead in concurrent environment.


> About the thread local storage, that is a sensible choice for highly
> concurrent systems, at the same time, web containers normally complain about
> orphaned thread locals created by an application and not cleaned up.
> Not sure if ones created at the core libs level get special treatment, but
> in general, I guess it would be nice to have some way to clean them up.
>

You're right that's why my patch is not ready !

I chose ThreadLocal for simplicity and clarity but I see several issues:
1/ Web container: ThreadLocal must be clean up when stopping an application
to avoid memory leaks (application becomes unloadable due to classloader
leaks)
2/ ThreadLocal access is the fastest way to get the RendererContext as it
does not require any lock (unsynchronized); As I get the RendererContext
once per rendering request, I think the ThreadLocal can be replaced by a
thread-safe ConcurrentLinkedQueue but it may become a
performance bootleneck
3/ Using a ConcurrentLinkedQueue requires an efficient /
proper cache eviction to free memory (Weak or Soft references ?) or using
statistics (last usage timestamp, usage counts)

Any other idea (core-libs) to have an efficient thread context in a web
container ?

I'm not familiar with the API, but is there any way to clean them up when
> the graphics2d gets disposed of?
>

The RenderingEngine is instanciated by the JVM once and I do not see in the
RenderingEngine interface any way to perform callbacks for warmup / cleanup
... nor access to the Graphics RenderingHints (other RFE for tuning
purposes)


> A web application has no guarantee to see the same thread ever again
> during his life, so thread locals have to be cleaned right away.
>

I advocate ThreadLocal can lead to wasted memory as only few concurrent
threads can really use their RendererContext instance while others can
simply answer web requests => let's use a
ConcurrentLinkedQueue with a proper cache eviction.


>
> Either that, or see if there is any way to store the array caches in a
> global structure backed by a concurrent collection to reduce/eliminate
> contention.
>

Yes, it is a interesting alternative to benchmark.

Regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From gnu.andrew at redhat.com  Wed Apr  3 14:42:20 2013
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 3 Apr 2013 10:42:20 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Fwd: requesting bug id for removing redundant
	fontconfig files
In-Reply-To: <515AC276.6010407@redhat.com>
References: <515AC276.6010407@redhat.com>
Message-ID: <165205663.831220.1365000140343.JavaMail.root@redhat.com>

[Forwarding to 2d-dev]

----- Forwarded Message -----
> Hi!
> 
> FontConfig  files are no longer necessary for jdk7 and 8. I have patch for
> their removal
> (http://jvanek.fedorapeople.org/oracle/jdk8/webrevs/removedFontConfigFiles/)
> and I have built and
> tested - looks ok.
> This approach was recommended at -
> http://mail.openjdk.java.net/pipermail/2d-dev/2012-May/002547.html.
> 
> To move forward with this issue I would like to have  bug id if possible.
> Later I would like to
> backport this also to JDK7.\
> 
> With kind regards
> Jiri Vanek
> 
> 

This looks ok to me.  I assume it builds?

There seems to generally be a lot of dead code in the jdk repository, which is
very confusing for fixing anything.  Glad to see some of it going.

Let's get it into 8 first, then we can backport to 7.  Oracle, can we have a bug ID please?
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From dan.xu at oracle.com  Wed Apr  3 14:53:41 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 03 Apr 2013 07:53:41 -0700
Subject: [OpenJDK 2D-Dev] Review Request: JDK-8000406 - change files
 using @GenerateNativeHeader to use @Native
In-Reply-To: <515B3361.6080503@oracle.com>
References: <515A0759.5070602@oracle.com> <515B3361.6080503@oracle.com>
Message-ID: <515C4275.80503@oracle.com>

Hi Phil,

Thank you for your good comments. Please see my answers below.

On 04/02/2013 12:37 PM, Phil Race wrote:
> The addition of @Native to various lines in SunGraphics2D.java look to 
> have pushed them >80 chars
> and it looks to me as if previously the author took some care to limit 
> it. Moreover the indentation
> of the comment block `on lines 127-130 is no longer aligned.
>
> Maybe it would be easier for that case to put the annotation on the 
> line above as in
> @Native
> static final int FOO ...
>
I use a program to automatically scan and modify files. And the length 
program is not noticed. I will fix the format issue.
>
> Otherwise looks OK, looks like you found files that had 
> @GenerateNativeHeaders that
> didn't need it and cleaned those up, and in native sources removed 
> unneeded header
> file imports too.
>
> I do have a background question about how it works.
> There is an implication here that only the constants with @native might
> be included in generated header files. Is that true ?
>
> Whereas if a class has native method declarations, then  it doesn't need
> these annotations, but you get all constants in the header file. Is 
> that right ?
>

If a class has native method declarations, then we don't need add 
anything. It will automatically generate the header file with all constants.

If a class contains no native methods but have constants interested by 
native codes, then we need annotations. Previously, we use 
@GenerateNativeHeader. But now we need replace them with @Native. 
@Native works on the field level. Only constants annotated with @native 
will be added as an entry in the generated native header file. (But we 
currently have a bug on this. It generates a header file with all 
constants no matter a constant has @Native or not. It will be fixed soon.)

In my change, I only add @Native annotation to constants interested by 
native codes. And if no such kind of constants and native methods 
declared, the fix does the clean-up and removes unnecessary header 
imports. Thanks!

-Dan

> -phil.
>
> On 4/1/13 3:16 PM, Dan Xu wrote:
>> Hi All,
>>
>> In this fix, I have updated files in JDK libraries to use @Native 
>> annotation instead of @GenerateNativeHeader  to mark classes that 
>> contain no native methods but constants used by native codes.
>>
>> @GenerateNativeHeader was added earlier in the development for 
>> JDK8."This has proved problematic for some core classes with respect 
>> to Jigsaw, since the use of such an annotation creates a compile-time 
>> dependency from the base module to the module containing javax.tools, 
>> and the base module should not have any dependencies." After 
>> switching to @Native annotation, the dependency problem will be 
>> solved as java.lang.annotation.Native is in the proposed base module. 
>> In addition, the annotation has been refined not to be on the class 
>> level but on the constants themselves, which also makes the generated 
>> header files much cleaner.
>>
>> This effort is part of JDK-8000404. After jdk libraries uptaking the 
>> annotation changes, @GenerateNativeHeader annotation will be removed 
>> completely.
>>
>> CCC: http://ccc.us.oracle.com/8000404
>> webrev: http://cr.openjdk.java.net/~dxu/8000406/webrev/
>>
>> Thanks for your feedback!
>>
>> -Dan
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From philip.race at oracle.com  Wed Apr  3 20:29:59 2013
From: philip.race at oracle.com (Phil Race)
Date: Wed, 03 Apr 2013 13:29:59 -0700
Subject: [OpenJDK 2D-Dev] [8] request for review: 8005930: [lcms]
 ColorConvertOp: Alpha channel is not transferred from source to
 destination.
In-Reply-To: <51388653.3010206@oracle.com>
References: <51388653.3010206@oracle.com>
Message-ID: <515C9147.40002@oracle.com>

That will fix the problem and is good enough for now, but it would be
better if there was a way to have native take an option to either ignore
(as now) or transfer an alpha channel. If this requires some changes
to LittleCMS we can try asking on the appropriate list. You may
want to file another bug to track it as a performance issue.

-phil.

On 3/7/2013 4:21 AM, Andrew Brygin wrote:
> Hello,
>
> could you please review a fix for 8005930?
>
> Bug: http://bugs.sun.com/view_bug.do?bug_id=8005930
> Webrev: http://cr.openjdk.java.net/~bae/8005930/8/webrev.00/
>
> Lcms color transform routine ignores any non-color channels
> in processed images. So if destination image has alpha, then
> we have to fall back to per-pixel image processing, which
> handles alpha correctly.
>
> Please take a look.
>
> Thanks,
> Andrew.



From jvanek at redhat.com  Thu Apr  4 07:42:44 2013
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 04 Apr 2013 09:42:44 +0200
Subject: [OpenJDK 2D-Dev] requesting bug id for error in fontmanager
 when no fonts are installed - RHBZ#862355
In-Reply-To: <515D149D.4080005@oracle.com>
References: <515AC749.5070306@redhat.com> <515D149D.4080005@oracle.com>
Message-ID: <515D2EF4.9040305@redhat.com>

On 04/04/2013 07:50 AM, David Holmes wrote:
> Hi Jiri,
>
> Seeing this has already been discussed:
>
> http://mail.openjdk.java.net/pipermail/2d-dev/2012-November/002869.html
>
> Shouldn't you be taking this up on the 2d-dev list ??



Yes, probably should. I thought bug ids are requested in more general list.
Deeply sorry for mess, and thank you for reply. Resending to 2d-dev.


J.

>
> David
>
> On 2/04/2013 9:55 PM, Jiri Vanek wrote:
>> Hi!
>>
>> When openjdk is used on headless devices (with no fonts), then it
>> crashes. See eg https://bugzilla.redhat.com/show_bug.cgi?id=862355.
>> I have patch (not 100% finished) for fontconfig manager for this, built,
>> and tested. (deeply only on linux). To move forward with this issue I
>> would like to ask for bug id in your bugzilla.
>>
>> With kind regards
>> Jiri Vanek



From bourges.laurent at gmail.com  Thu Apr  4 13:44:48 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 4 Apr 2013 15:44:48 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
	<5154ACCD.5090105@oracle.com>
	
	
	
	
	
	
	
	
Message-ID: 

I updated both patched pisces code and benchmarks:
http://jmmc.fr/~bourgesl/share/java2d-pisces/

Few results comparing ThreadLocal vs ConcurrentLinkedQueue usage:

OpenJDK 8 PATCH ThreadLocal mode:
Testing file
/home/bourgesl/libs/openjdk/mapbench/test/dc_boulder_2013-13-30-06-13-17.ser
1 threads and 20 loops per thread, time: 2671 ms
2 threads and 20 loops per thread, time: 3239 ms
4 threads and 20 loops per thread, time: 6043 ms

OpenJDK 8 PATCH ConcurrentLinkedQueue mode:
Testing file
/home/bourgesl/libs/openjdk/mapbench/test/dc_boulder_2013-13-30-06-13-17.ser
1 threads and 20 loops per thread, time: 2779 ms
2 threads and 20 loops per thread, time: 3416 ms
4 threads and 20 loops per thread, time: 6153 ms

Oracle JDK8 Ductus:
Testing file
/home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser
1 threads and 20 loops per thread, time: 1894 ms
2 threads and 20 loops per thread, time: 3905 ms
4 threads and 20 loops per thread, time: 7485 ms


OpenJDK 8 PATCH ThreadLocal mode:
Testing file
/home/bourgesl/libs/openjdk/mapbench/test/dc_shp_alllayers_2013-00-30-07-00-47.ser
1 threads and 20 loops per thread, time: 24211 ms
2 threads and 20 loops per thread, time: 30955 ms
*4 threads and 20 loops per thread, time: 67715 ms*

OpenJDK 8 PATCH ConcurrentLinkedQueue mode:
Testing file
/home/bourgesl/libs/openjdk/mapbench/test/dc_shp_alllayers_2013-00-30-07-00-47.ser
1 threads and 20 loops per thread, time: 25984 ms
2 threads and 20 loops per thread, time: 33131 ms
*4 threads and 20 loops per thread, time: 75343 ms
*
Oracle JDK8 Ductus:
Loading drawing commands from file:
/home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
Loaded DrawingCommands: DrawingCommands{width=1400, height=800,
commands=135213}
1 threads and 20 loops per thread, time: 20911 ms
2 threads and 20 loops per thread, time: 39297 ms
4 threads and 20 loops per thread, time: 103392 ms

ConcurrentLinkedQueue add a small overhead but not too much vs ThreadLocal.

Is it possible to test efficiently if the current thread is EDT then I
could use ThreadLocal for EDT at least ? it must be very fast because
getThreadContext() is called once per rendering operation so it is a
performance bottleneck.

For example:
Testing file
/home/bourgesl/libs/openjdk/mapbench/test/dc_shp_alllayers_2013-00-30-07-00-47.ser
TL:  4 threads and 20 loops per thread, time: 67715 ms
CLQ: 4 threads and 20 loops per thread, time: 75343 ms

Changes:
- use ThreadLocal or ConcurrentLinkedQueue to get a
renderer context (vars / cache)
- use first RendererContext (dirty / clean arrays) members instead of using
IntArrayCache / FloatArrayCache for performance reasons (dedicated to large
dynamic arrays)

TBD:
- recycle pisces class i.e. keep only one instance per class (Renderer,
Stroker ...) to avoid totally GC overhead (several thousands per MapBench
test).

Moreover, these are very small objects / short lived i.e. l so it should
stay in ThreadLocalAllocator (TLAB) but when I use verbose:gc or jmap
-histo these are present and represents megabytes:
[bourgesl at jmmc-laurent ~]$ jmap -histo:live 21628 | grep pisces
   5:         50553        6470784  sun.java2d.pisces.Renderer
   9:         29820        3578400  sun.java2d.pisces.Stroker
  11:         49795        3186880  sun.java2d.pisces.PiscesCache
  12:         49794        1991760  sun.java2d.pisces.PiscesTileGenerator
  13:         49793        1991720
sun.java2d.pisces.Renderer$ScanlineIterator
  14:         29820        1431360
sun.java2d.pisces.PiscesRenderingEngine$NormalizingPathIterator
  52:            40           1280  sun.java2d.pisces.IntArrayCache
  94:            20            640  sun.java2d.pisces.FloatArrayCache
 121:             8            320  [Lsun.java2d.pisces.IntArrayCache;
 127:             4            320  sun.java2d.pisces.RendererContext
 134:             4            256  sun.java2d.pisces.Curve
 154:             4            160  [Lsun.java2d.pisces.FloatArrayCache;
 155:             4            160
sun.java2d.pisces.RendererContext$RendererData
 156:             4            160
sun.java2d.pisces.RendererContext$StrokerData
 157:             4            160  sun.java2d.pisces.Stroker$PolyStack
 208:             3             72
sun.java2d.pisces.PiscesRenderingEngine$NormMode
 256:             1             32
[Lsun.java2d.pisces.PiscesRenderingEngine$NormMode;
 375:             1             16  sun.java2d.pisces.PiscesRenderingEngine
 376:             1             16  sun.java2d.pisces.RendererContext$1

Regards,
Laurent

2013/4/3 Laurent Bourg?s 

> Thanks for your valueable feedback!
>
> Here is the current status of my patch alpha version:
>>> http://jmmc.fr/~bourgesl/share/java2d-pisces/
>>>
>>> There is still a lot to be done: clean-up, stats, pisces class instance
>>> recycling (renderer, stroker ...) and of course sizing correctly initial
>>> arrays (dirty or clean) in the RendererContext (thread local storage).
>>> For performance reasons, I am using now RendererContext members first
>>> (cache for rowAARLE for example) before using ArrayCaches (dynamic arrays).
>>>
>>
>> Thank you Laurent, those are some nice speedups.
>>
> I think it can still be improved: I hope to make it as fast as ductus or
> maybe more (I have several idea for aggressive optimizations) but the main
> improvement consist in reusing memory (like C / C++ does) to avoid wasted
> memory / GC overhead in concurrent environment.
>
>
>> About the thread local storage, that is a sensible choice for highly
>> concurrent systems, at the same time, web containers normally complain about
>> orphaned thread locals created by an application and not cleaned up.
>> Not sure if ones created at the core libs level get special treatment,
>> but in general, I guess it would be nice to have some way to clean them up.
>>
>
> You're right that's why my patch is not ready !
>
> I chose ThreadLocal for simplicity and clarity but I see several issues:
> 1/ Web container: ThreadLocal must be clean up when stopping an
> application to avoid memory leaks (application becomes unloadable due to
> classloader leaks)
> 2/ ThreadLocal access is the fastest way to get the RendererContext as it
> does not require any lock (unsynchronized); As I get the RendererContext
> once per rendering request, I think the ThreadLocal can be replaced by a
> thread-safe ConcurrentLinkedQueue but it may become a
> performance bootleneck
> 3/ Using a ConcurrentLinkedQueue requires an efficient /
> proper cache eviction to free memory (Weak or Soft references ?) or using
> statistics (last usage timestamp, usage counts)
>
> Any other idea (core-libs) to have an efficient thread context in a web
> container ?
>
> I'm not familiar with the API, but is there any way to clean them up when
>> the graphics2d gets disposed of?
>>
>
> The RenderingEngine is instanciated by the JVM once and I do not see in
> the RenderingEngine interface any way to perform callbacks for warmup /
> cleanup ... nor access to the Graphics RenderingHints (other RFE for tuning
> purposes)
>
>
>> A web application has no guarantee to see the same thread ever again
>> during his life, so thread locals have to be cleaned right away.
>>
>
> I advocate ThreadLocal can lead to wasted memory as only few concurrent
> threads can really use their RendererContext instance while others can
> simply answer web requests => let's use a
> ConcurrentLinkedQueue with a proper cache eviction.
>
>
>>
>> Either that, or see if there is any way to store the array caches in a
>> global structure backed by a concurrent collection to reduce/eliminate
>> contention.
>>
>
> Yes, it is a interesting alternative to benchmark.
>
> Regards,
> Laurent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bourges.laurent at gmail.com  Fri Apr  5 12:20:20 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 5 Apr 2013 14:20:20 +0200
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
Message-ID: 

Dear java2d members,

I figured out some troubles in java2d.pipe.AAShapePipe related to both
concurrency & memory usage:
- concurrency issue related to static theTile field: only 1 tile is cached
so a new byte[] is created for other threads at each call to renderTile()
- excessive memory usage (byte[] for tile, int[] and rectangle): at each
call to renderPath / renderTiles, several small objects are created (never
cached) that leads to hundreds megabytes that GC must deal with

Here are profiling screenshots:
- 4 threads drawing on their own buffered image (MapBench test):
http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_byte_tile.png

- excessive int[] / Rectangle creation:
http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_int_bbox.png
http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_rectangle_bbox.png

Here is the proposed patch:
http://jmmc.fr/~bourgesl/share/AAShapePipe/webrev-1/

I applied a simple solution = use a ThreadLocal or ConcurrentLinkedQueue
(see useThreadLocal flag) to cache one AAShapePipeContext per thread (2K
max).
As its memory footprint is very small, I recommend using ThreadLocal.

Is it necessary to use Soft/Weak reference to avoid excessive memory usage
for such cache ?

Is there any class dedicated to such cache (ThreadLocal with cache eviction
or ConcurrentLinkedQueue using WeakReference ?) ?
I think it could be very useful at the JDK level to have such feature (ie a
generic "GC friendly"cache )

Regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bourges.laurent at gmail.com  Fri Apr  5 14:32:00 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 5 Apr 2013 16:32:00 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
	<5154ACCD.5090105@oracle.com>
	
	
	
	
	
	
	
	
	
Message-ID: 

Dear all,

Here is my first pisces (beta) patch (webrev):
http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/

I succeed in fixing memory usage by having only 1 pisces instance
(Renderer, stroker, iterator ...) per RendererContext (GC friendly).

Impressive results between small and large drawings:


dc_boulder_2013-13-30-06-13-17.ser dc_shp_alllayers_2013-00-30-07-00-47.ser
JVM 1T 2T 4T 1T 2T 4T  OpenJDK8 Patch Beta 2556 3190 5106 22952 26552
46010  OpenJDK8
Ref 3982 4852 8842 55889 77691 141981  Oracle JDK8 (ductus) 1894 3905 7485
20911 39297 103392






 Patch / REF *155,79%* *152,10%* *173,17%* *243,50%* *292,60%* *308,59%*  Patch
/ Ductus 74,10% *122,41%* *146,59%* 91,11% *148,00%* *224,72%*
Low mem tests: -Xmx128m to maximize GC overhead

http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench_PATCH_V1.log (beta)
http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench_REF.log
http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench_OracleDuctus.log

Andrea, I modify the MapBench to perform explicit GC between tests (+
creating graphics / image out of the test loop):
http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench/

Note: these results were performed with the AAShapePipe proposed patch
(small impact).

Is there somebody interested to enhance Pisces renderer code and support me
as sponsor ?

Look at PiscesConst to enable/disable several flags (useThreadLocal,
doChecks to check array cleanup ...); please ask me if you have any
question.

TBD:
- cleanup / statistics / profile cpu performance ...
- enhance Dasher / Stroker to deal with shape out or partially out the
clipping area.

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Fri Apr  5 16:54:06 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 05 Apr 2013 20:54:06 +0400
Subject: [OpenJDK 2D-Dev] [8] Request for review: 8000629 [macosx]
 Blurry rendering with Java 7 on Retina display
In-Reply-To: <5151BFCA.1060702@oracle.com>
References: <5151BFCA.1060702@oracle.com>
Message-ID: <515F01AE.4050409@oracle.com>

Hi, Jim.
I assume, that you haven't additional comments? Can I consider you as 
the second reviewer?
Note that I plan push it to awt-dev because, my other fixes depend on it.

On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk 8.
> Change adds initial support of hidpi(mostly on 2d side). In the fix 
> scale was added to the surface data/CGraphicsDevice /CGLLayer. This 
> scale factor maps virtual coordinates to physical pixels.
> This change doesn't add support of hidpi to aqua l&f and doesn't add 
> support of dynamic change of scale factor.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8000629/webrev.06
> -- 
> Best regards, Sergey.


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From philip.race at oracle.com  Fri Apr  5 18:00:01 2013
From: philip.race at oracle.com (Phil Race)
Date: Fri, 05 Apr 2013 11:00:01 -0700
Subject: [OpenJDK 2D-Dev]  [8] Request for review: 8000629
 [macosx] Blurry rendering with Java 7 on Retina display
In-Reply-To: <515F01AE.4050409@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
Message-ID: <515F1121.4020107@oracle.com>

SFAIK you haven't fixed the problem with TexturePaint I pointed out last 
week.
That needs to be fixed before you push.

-phil.

On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
> Hi, Jim.
> I assume, that you haven't additional comments? Can I consider you as 
> the second reviewer?
> Note that I plan push it to awt-dev because, my other fixes depend on it.
>
> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>> Hello,
>> Please review the fix for jdk 8.
>> Change adds initial support of hidpi(mostly on 2d side). In the fix 
>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This 
>> scale factor maps virtual coordinates to physical pixels.
>> This change doesn't add support of hidpi to aqua l&f and doesn't add 
>> support of dynamic change of scale factor.
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>> -- 
>> Best regards, Sergey.
>
>
> -- 
> Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Fri Apr  5 18:10:52 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 05 Apr 2013 22:10:52 +0400
Subject: [OpenJDK 2D-Dev]  [8] Request for review: 8000629
 [macosx] Blurry rendering with Java 7 on Retina display
In-Reply-To: <515F1121.4020107@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com>
Message-ID: <515F13AC.50907@oracle.com>

Hi, Phil.
Could you please send me a screenshot and steps to reproduce.
Note that you should change hidpi mode before start j2ddemo.

On 4/5/13 10:00 PM, Phil Race wrote:
> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
> last week.
> That needs to be fixed before you push.
>
> -phil.
>
> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>> Hi, Jim.
>> I assume, that you haven't additional comments? Can I consider you as 
>> the second reviewer?
>> Note that I plan push it to awt-dev because, my other fixes depend on 
>> it.
>>
>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk 8.
>>> Change adds initial support of hidpi(mostly on 2d side). In the fix 
>>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This 
>>> scale factor maps virtual coordinates to physical pixels.
>>> This change doesn't add support of hidpi to aqua l&f and doesn't add 
>>> support of dynamic change of scale factor.
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>> -- 
>>> Best regards, Sergey.
>>
>>
>> -- 
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.



From andrea.aime at geo-solutions.it  Sun Apr  7 19:11:18 2013
From: andrea.aime at geo-solutions.it (Andrea Aime)
Date: Sun, 7 Apr 2013 21:11:18 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
	<5154ACCD.5090105@oracle.com>
	
	
	
	
	
	
	
	
	
	
Message-ID: 

On Fri, Apr 5, 2013 at 4:32 PM, Laurent Bourg?s
wrote:

> Dear all,
>
> Here is my first pisces (beta) patch (webrev):
> http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/
>
> I succeed in fixing memory usage by having only 1 pisces instance
> (Renderer, stroker, iterator ...) per RendererContext (GC friendly).
>
> Impressive results between small and large drawings:
>

Good stuff. Is there anything I can do to help? I do have an up to date
version of JDK 8 sources on my disk, maybe I could
try to apply the patch and take it for a spin in a real GeoServer and see
how it goes.

By the way, wondering, is there any other benchmark to try out?
A possibly interesting one is this, where the author re-coded some selected
methods of Graphics2D for maximum performance
(but sometimes lower antialiasing quality) and created a applet to compare
the results in a number of synthetic test cases:
http://www.randelshofer.ch/oop/graphics/

Cheers
Andrea


-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bourges.laurent at gmail.com  Mon Apr  8 07:48:28 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Mon, 8 Apr 2013 09:48:28 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
	<5154ACCD.5090105@oracle.com>
	
	
	
	
	
	
	
	
	
	
	
Message-ID: 

Andrea,

Any feedback from anybody else ?

Here are J2D Bench results:
http://jmmc.fr/~bourgesl/share/java2d-pisces/j2DBench/

Depending on the test, performance gains varies from 20% to 100% !

I think it could be nice if you can perform tests (regression and
benchmarks using MapBench, J2DBench, Java2D demos).
I still have to enhance cleanup / tuning my code (stats, initial array
sizes ...) and cache eviction (memory cleanup) using Weak references or
manual cleanup using timestamps ...

To test regression, I propose you to enhance your MapBench class to save
image results (randomly in tests) and compare them after the test run
(image diff) even when multiple threads are in use.

If you apply my patch, take care of the following main settings:
useThreadLocal should be disabled in a web container (to avoid too much
memory waste): a RendererContext represents ~ 2Mb:
rowAARLE = new int[INITIAL_Y_ARRAY][INITIAL_ARRAY]; // ~2Mb +1 to avoid
recycling such shared arrays

PiscesConst:
    /** use ThreadLocal or ConcurrentLinkedQueue to get the thread
RendererContext */
    static final boolean useThreadLocal = true;

Initial RendererContext array capacity:
    // +1 to avoid recycling such shared arrays
    static final int INITIAL_ARRAY = 256 + 1;
    static final int INITIAL_Y_ARRAY = 2048 + 1;
    static final int INITIAL_LARGE_ARRAY = 16384 + 1; // large

Laurent

2013/4/7 Andrea Aime 

> On Fri, Apr 5, 2013 at 4:32 PM, Laurent Bourg?s  > wrote:
>
>> Dear all,
>>
>> Here is my first pisces (beta) patch (webrev):
>> http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/
>>
>> I succeed in fixing memory usage by having only 1 pisces instance
>> (Renderer, stroker, iterator ...) per RendererContext (GC friendly).
>>
>> Impressive results between small and large drawings:
>>
>
> Good stuff. Is there anything I can do to help? I do have an up to date
> version of JDK 8 sources on my disk, maybe I could
> try to apply the patch and take it for a spin in a real GeoServer and see
> how it goes.
>
> By the way, wondering, is there any other benchmark to try out?
> A possibly interesting one is this, where the author re-coded some
> selected methods of Graphics2D for maximum performance
> (but sometimes lower antialiasing quality) and created a applet to compare
> the results in a number of synthetic test cases:
> http://www.randelshofer.ch/oop/graphics/
>
> Cheers
> Andrea
>
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jvanek at redhat.com  Mon Apr  8 10:53:39 2013
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 08 Apr 2013 12:53:39 +0200
Subject: [OpenJDK 2D-Dev] [PATCH FOR REVIEW] fix for bug 8011693: Remove
 redundant fontconfig files
Message-ID: <5162A1B3.1050001@redhat.com>

Hi!

As fontconfig.properties  files are no longer necessary for jdk7/8 and theirs deletion was suggested 
above, I would like to offer this clean-up[1] for jdk8(7 if possible later too)

I have tested on fedora, and jdk8 built and run correctly.


  Best regards
    Jiri Vanek


[1] http://jvanek.fedorapeople.org/oracle/jdk8/webrevs/removedFontConfigFiles/


From Vladislav.Karnaukhov at oracle.com  Mon Apr  8 11:13:06 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Mon, 08 Apr 2013 15:13:06 +0400
Subject: [OpenJDK 2D-Dev] [PATCH FOR REVIEW] fix for bug 8011693: Remove
 redundant fontconfig files
In-Reply-To: <5162A1B3.1050001@redhat.com>
References: <5162A1B3.1050001@redhat.com>
Message-ID: <5162A642.4020003@oracle.com>

I'm quite surprised to hear that fontconfig.properties file are now 
redundant... I've worked on some fontconfig issues just recently, and I 
cannot say that fontconfig.* files are in any way "unnecessary"...

A removal of fontconfig.* files will require a very thorough 
re-evaluation and re-design of many JDK classes, as well a very 
exhaustive testing.

Am I missing something here?

Regards,
- Vlad

On 4/8/2013 02:53 PM, Jiri Vanek wrote:
> Hi!
>
> As fontconfig.properties  files are no longer necessary for jdk7/8 and
> theirs deletion was suggested above, I would like to offer this
> clean-up[1] for jdk8(7 if possible later too)
>
> I have tested on fedora, and jdk8 built and run correctly.
>
>
>   Best regards
>     Jiri Vanek
>
>
> [1]
> http://jvanek.fedorapeople.org/oracle/jdk8/webrevs/removedFontConfigFiles/




From jvanek at redhat.com  Mon Apr  8 11:35:43 2013
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 08 Apr 2013 13:35:43 +0200
Subject: [OpenJDK 2D-Dev] [PATCH FOR REVIEW] fix for bug 8011693: Remove
 redundant fontconfig files
In-Reply-To: <5162A642.4020003@oracle.com>
References: <5162A1B3.1050001@redhat.com> <5162A642.4020003@oracle.com>
Message-ID: <5162AB8F.1020503@redhat.com>

On 04/08/2013 01:13 PM, Vladislav Karnaukhov wrote:
> I'm quite surprised to hear that fontconfig.properties file are now redundant... I've worked on some
> fontconfig issues just recently, and I cannot say that fontconfig.* files are in any way
> "unnecessary"...
>
> A removal of fontconfig.* files will require a very thorough re-evaluation and re-design of many JDK
> classes, as well a very exhaustive testing.
>
> Am I missing something here?

Yap, I guess you do.
Try to remove them, and you can be surprised that your configurations will work better then with them.

Probably better then my words will be to read Phils answers from nearly year ago:
http://mail.openjdk.java.net/pipermail/2d-dev/2012-May/002528.html
and especially
http://mail.openjdk.java.net/pipermail/2d-dev/2012-May/002547.html

However, I'm 100% sure just for linux based builds. For windows I'm going to test later, but have no 
idea where to test Mac....

Please note, this is for jdk7+8. Jdk6 still needs those config files.

Best regards,
    J.

> On 4/8/2013 02:53 PM, Jiri Vanek wrote:
>> Hi!
>>
>> As fontconfig.properties  files are no longer necessary for jdk7/8 and
>> theirs deletion was suggested above, I would like to offer this
>> clean-up[1] for jdk8(7 if possible later too)
>>
>> I have tested on fedora, and jdk8 built and run correctly.
>>
>>
>>   Best regards
>>     Jiri Vanek
>>
>>
>> [1]
>> http://jvanek.fedorapeople.org/oracle/jdk8/webrevs/removedFontConfigFiles/
>
>



From Vladislav.Karnaukhov at oracle.com  Mon Apr  8 12:39:05 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Mon, 08 Apr 2013 16:39:05 +0400
Subject: [OpenJDK 2D-Dev] [PATCH FOR REVIEW] fix for bug 8011693: Remove
 redundant fontconfig files
In-Reply-To: <5162AB8F.1020503@redhat.com>
References: <5162A1B3.1050001@redhat.com> <5162A642.4020003@oracle.com>
	<5162AB8F.1020503@redhat.com>
Message-ID: <5162BA69.8070308@oracle.com>

Hi Jiri,

I've tested Windows build (fresh open jdk8 clone + your patch) and 
unfortunately it failed:

=========================================================
BUILDTOOL:                commentchecker
PACKAGE:                  build.tools.commentchecker
BUILDTOOL_SOURCE_ROOT:    ../../tools/src
BUILTTOOL_MAINCLASS:      build.tools.commentchecker.CommentChecker
BUILDTOOL_JAR_FILE:       c:/build/jdk8-open-debug/btjars/commentchecker.jar
=========================================================
make[4]: Leaving directory 
`/cygdrive/c/projects/jdk8-open/jdk/make/tools/commentchecker'
make: Entering an unknown directory
make: *** compile_font_config: No such file or directory.  Stop.
make: Leaving an unknown directory
make[3]: *** [all] Error 1
make[3]: Leaving directory `/cygdrive/c/projects/jdk8-open/jdk/make/tools'
make[2]: *** [all] Error 1
make[2]: Leaving directory `/cygdrive/c/projects/jdk8-open/jdk/make'
make[1]: *** [jdk-build] Error 2
make[1]: Leaving directory `/cygdrive/c/projects/jdk8-open'
make: *** [build_product_image] Error 2

I hope this will help.

Regards,
- Vlad

On 4/8/2013 03:35 PM, Jiri Vanek wrote:
> On 04/08/2013 01:13 PM, Vladislav Karnaukhov wrote:
>> I'm quite surprised to hear that fontconfig.properties file are now
>> redundant... I've worked on some
>> fontconfig issues just recently, and I cannot say that fontconfig.*
>> files are in any way
>> "unnecessary"...
>>
>> A removal of fontconfig.* files will require a very thorough
>> re-evaluation and re-design of many JDK
>> classes, as well a very exhaustive testing.
>>
>> Am I missing something here?
>
> Yap, I guess you do.
> Try to remove them, and you can be surprised that your configurations
> will work better then with them.
>
> Probably better then my words will be to read Phils answers from nearly
> year ago:
> http://mail.openjdk.java.net/pipermail/2d-dev/2012-May/002528.html
> and especially
> http://mail.openjdk.java.net/pipermail/2d-dev/2012-May/002547.html
>
> However, I'm 100% sure just for linux based builds. For windows I'm
> going to test later, but have no idea where to test Mac....
>
> Please note, this is for jdk7+8. Jdk6 still needs those config files.
>
> Best regards,
>     J.
>
>> On 4/8/2013 02:53 PM, Jiri Vanek wrote:
>>> Hi!
>>>
>>> As fontconfig.properties  files are no longer necessary for jdk7/8 and
>>> theirs deletion was suggested above, I would like to offer this
>>> clean-up[1] for jdk8(7 if possible later too)
>>>
>>> I have tested on fedora, and jdk8 built and run correctly.
>>>
>>>
>>>   Best regards
>>>     Jiri Vanek
>>>
>>>
>>> [1]
>>> http://jvanek.fedorapeople.org/oracle/jdk8/webrevs/removedFontConfigFiles/
>>>
>>
>>
>




From Sergey.Bylokhov at oracle.com  Mon Apr  8 13:10:21 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 08 Apr 2013 17:10:21 +0400
Subject: [OpenJDK 2D-Dev]  [8] Request for review: 8000629
 [macosx] Blurry rendering with Java 7 on Retina display
In-Reply-To: <515F1121.4020107@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com>
Message-ID: <5162C1BD.8070703@oracle.com>

Hi, Phil, JIm.
New version of the fix:
http://cr.openjdk.java.net/~serb/8000629/webrev.08
  - Assumption that we should scale all native surfaces was wrong. In 
case of managed Bufferedimage we shouldn't scale native surface, because 
they are copies 1-1.(CGLSurfaceData.java:60).
  - BufferedContext is not always updates current Paint, because it 
checks transX/transY from sg2d, which is not maintained in the scale mode.
Test: FillTexturePaint.java

Also I found a problem in the sg2d.getTransform(), where invScale does 
not apply to constrainX/Y.
Test: TransformSetGet.java

On 4/5/13 10:00 PM, Phil Race wrote:
> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
> last week.
> That needs to be fixed before you push.
>
> -phil.
>
> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>> Hi, Jim.
>> I assume, that you haven't additional comments? Can I consider you as 
>> the second reviewer?
>> Note that I plan push it to awt-dev because, my other fixes depend on 
>> it.
>>
>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk 8.
>>> Change adds initial support of hidpi(mostly on 2d side). In the fix 
>>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This 
>>> scale factor maps virtual coordinates to physical pixels.
>>> This change doesn't add support of hidpi to aqua l&f and doesn't add 
>>> support of dynamic change of scale factor.
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>> -- 
>>> Best regards, Sergey.
>>
>>
>> -- 
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jvanek at redhat.com  Mon Apr  8 13:29:56 2013
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 08 Apr 2013 15:29:56 +0200
Subject: [OpenJDK 2D-Dev] [PATCH FOR REVIEW] fix for bug 8011693: Remove
 redundant fontconfig files
In-Reply-To: <5162BA69.8070308@oracle.com>
References: <5162A1B3.1050001@redhat.com> <5162A642.4020003@oracle.com>
	<5162AB8F.1020503@redhat.com> <5162BA69.8070308@oracle.com>
Message-ID: <5162C654.3070001@redhat.com>

On 04/08/2013 02:39 PM, Vladislav Karnaukhov wrote:
> Hi Jiri,
>
> I've tested Windows build (fresh open jdk8 clone + your patch) and unfortunately it failed:
>
> =========================================================
> BUILDTOOL:                commentchecker
> PACKAGE:                  build.tools.commentchecker
> BUILDTOOL_SOURCE_ROOT:    ../../tools/src
> BUILTTOOL_MAINCLASS:      build.tools.commentchecker.CommentChecker
> BUILDTOOL_JAR_FILE:       c:/build/jdk8-open-debug/btjars/commentchecker.jar
> =========================================================
> make[4]: Leaving directory `/cygdrive/c/projects/jdk8-open/jdk/make/tools/commentchecker'
> make: Entering an unknown directory
> make: *** compile_font_config: No such file or directory.  Stop.
> make: Leaving an unknown directory
> make[3]: *** [all] Error 1
> make[3]: Leaving directory `/cygdrive/c/projects/jdk8-open/jdk/make/tools'
> make[2]: *** [all] Error 1
> make[2]: Leaving directory `/cygdrive/c/projects/jdk8-open/jdk/make'
> make[1]: *** [jdk-build] Error 2
> make[1]: Leaving directory `/cygdrive/c/projects/jdk8-open'
> make: *** [build_product_image] Error 2
>
> I hope this will help.
>

Thank you very much for win-check! It will force me to install new windows machine somewhere.
Do you mind do check if pure removal of fontconfig files (both src and bfc)  from you installed 
jdk7/8 on windows will work? (should)

although the quick-fix would be easy - to remove "  compile_font_config " line from 
jdk/make/tools/Makefile... But need deeper investigations on my side, as on linux my build really 
passed:(


Thank you one more times for sticking with this!

J .

> On 4/8/2013 03:35 PM, Jiri Vanek wrote:
>> On 04/08/2013 01:13 PM, Vladislav Karnaukhov wrote:
>>> I'm quite surprised to hear that fontconfig.properties file are now
>>> redundant... I've worked on some
>>> fontconfig issues just recently, and I cannot say that fontconfig.*
>>> files are in any way
>>> "unnecessary"...
>>>
>>> A removal of fontconfig.* files will require a very thorough
>>> re-evaluation and re-design of many JDK
>>> classes, as well a very exhaustive testing.
>>>
>>> Am I missing something here?
>>
>> Yap, I guess you do.
>> Try to remove them, and you can be surprised that your configurations
>> will work better then with them.
>>
>> Probably better then my words will be to read Phils answers from nearly
>> year ago:
>> http://mail.openjdk.java.net/pipermail/2d-dev/2012-May/002528.html
>> and especially
>> http://mail.openjdk.java.net/pipermail/2d-dev/2012-May/002547.html
>>
>> However, I'm 100% sure just for linux based builds. For windows I'm
>> going to test later, but have no idea where to test Mac....
>>
>> Please note, this is for jdk7+8. Jdk6 still needs those config files.
>>
>> Best regards,
>>     J.
>>
>>> On 4/8/2013 02:53 PM, Jiri Vanek wrote:
>>>> Hi!
>>>>
>>>> As fontconfig.properties  files are no longer necessary for jdk7/8 and
>>>> theirs deletion was suggested above, I would like to offer this
>>>> clean-up[1] for jdk8(7 if possible later too)
>>>>
>>>> I have tested on fedora, and jdk8 built and run correctly.
>>>>
>>>>
>>>>   Best regards
>>>>     Jiri Vanek
>>>>
>>>>
>>>> [1]
>>>> http://jvanek.fedorapeople.org/oracle/jdk8/webrevs/removedFontConfigFiles/
>>>>
>>>
>>>
>>
>
>



From Vladislav.Karnaukhov at oracle.com  Mon Apr  8 14:13:48 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Mon, 08 Apr 2013 18:13:48 +0400
Subject: [OpenJDK 2D-Dev] [PATCH FOR REVIEW] fix for bug 8011693: Remove
 redundant fontconfig files
In-Reply-To: <5162C654.3070001@redhat.com>
References: <5162A1B3.1050001@redhat.com> <5162A642.4020003@oracle.com>
	<5162AB8F.1020503@redhat.com> <5162BA69.8070308@oracle.com>
	<5162C654.3070001@redhat.com>
Message-ID: <5162D09C.8000307@oracle.com>

Hello Jiri,

please see inline.

On 4/8/2013 05:29 PM, Jiri Vanek wrote:
> On 04/08/2013 02:39 PM, Vladislav Karnaukhov wrote:
>
> Thank you very much for win-check! It will force me to install new
> windows machine somewhere.
> Do you mind do check if pure removal of fontconfig files (both src and
> bfc)  from you installed jdk7/8 on windows will work? (should)

Yes, I've checked and it does *not* work. That's the reason why I 
replied to your very first message. A removal of fontconfig.* files 
simply crashes Java, - on both Windows and Mac, - because some font 
management-related classes rely on these files. Hence my question 
regarding deeper re-design on font management system...

I've tested Mac build as well, and there's the same error:

echo "Main-Class: build.tools.commentchecker.CommentChecker" > 
/Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btclasses/commentchecker_manifest.mf
/Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home/bin/javac 
-J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions 
-J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput 
-J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m 
-J-XX:MaxPermSize=160m -Xlint:all -Xlint:-path -Werror -encoding ascii 
-XDignore.symbol.file=true -d 
/Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btclasses \
	    -sourcepath ../../tools/src 
../../tools/src/build/tools/commentchecker/CommentChecker.java
/Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home/bin/jar 
cfm 
/Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btjars/commentchecker.jar 
/Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btclasses/commentchecker_manifest.mf 
\
	    -C 
/Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btclasses 
build/tools/commentchecker \
	    -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions 
-J-XX:-LogVMOutput -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m 
-J-XX:PermSize=32m -J-XX:MaxPermSize=160m || rm -f 
/Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btjars/commentchecker.jar
=========================================================
BUILDTOOL:                commentchecker
PACKAGE:                  build.tools.commentchecker
BUILDTOOL_SOURCE_ROOT:    ../../tools/src
BUILTTOOL_MAINCLASS:      build.tools.commentchecker.CommentChecker
BUILDTOOL_JAR_FILE: 
/Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btjars/commentchecker.jar
=========================================================
make: *** compile_font_config: No such file or directory.  Stop.
make[3]: *** [all] Error 1
make[2]: *** [all] Error 1
make[1]: *** [jdk-build] Error 2
make: *** [build_product_image] Error 2

Regards,
- Vlad

>
> although the quick-fix would be easy - to remove "  compile_font_config
> " line from jdk/make/tools/Makefile... But need deeper investigations on
> my side, as on linux my build really passed:(
>
>
> Thank you one more times for sticking with this!
>
> J .
>


From jvanek at redhat.com  Mon Apr  8 15:31:10 2013
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 08 Apr 2013 17:31:10 +0200
Subject: [OpenJDK 2D-Dev] [PATCH FOR REVIEW] fix for bug 8011693: Remove
 redundant fontconfig files
In-Reply-To: <5162D09C.8000307@oracle.com>
References: <5162A1B3.1050001@redhat.com> <5162A642.4020003@oracle.com>
	<5162AB8F.1020503@redhat.com> <5162BA69.8070308@oracle.com>
	<5162C654.3070001@redhat.com> <5162D09C.8000307@oracle.com>
Message-ID: <5162E2BE.7000202@redhat.com>

On 04/08/2013 04:13 PM, Vladislav Karnaukhov wrote:
> Hello Jiri,
>
> please see inline.
>
> On 4/8/2013 05:29 PM, Jiri Vanek wrote:
>> On 04/08/2013 02:39 PM, Vladislav Karnaukhov wrote:
>>
>> Thank you very much for win-check! It will force me to install new
>> windows machine somewhere.
>> Do you mind do check if pure removal of fontconfig files (both src and
>> bfc)  from you installed jdk7/8 on windows will work? (should)
>
> Yes, I've checked and it does *not* work. That's the reason why I replied to your very first
> message. A removal of fontconfig.* files simply crashes Java, - on both Windows and Mac, - because
> some font management-related classes rely on these files. Hence my question regarding deeper
> re-design on font management system...
>
> I've tested Mac build as well, and there's the same error:

Ok. I will try anyway:)
For linux I'm quite sure the new fontmanagers are working pretty fine.
Do you think it will be acceptable to prepare smaller clean up - to  remove all linux fontconfig files?

And later, as separate changeset to  fontmanagers for windows/mac, but I'm afraid I will not be 
capable of such an development on non linux system.

Thanx for your help,

  J.
>
> echo "Main-Class: build.tools.commentchecker.CommentChecker" >
> /Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btclasses/commentchecker_manifest.mf
> /Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home/bin/javac -J-XX:ThreadStackSize=1536
> -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Djava.awt.headless=true
> -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -Xlint:all -Xlint:-path -Werror
> -encoding ascii -XDignore.symbol.file=true -d
> /Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btclasses \
>          -sourcepath ../../tools/src ../../tools/src/build/tools/commentchecker/CommentChecker.java
> /Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home/bin/jar cfm
> /Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btjars/commentchecker.jar
> /Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btclasses/commentchecker_manifest.mf \
>          -C /Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btclasses
> build/tools/commentchecker \
>          -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
> -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m || rm -f
> /Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btjars/commentchecker.jar
> =========================================================
> BUILDTOOL:                commentchecker
> PACKAGE:                  build.tools.commentchecker
> BUILDTOOL_SOURCE_ROOT:    ../../tools/src
> BUILTTOOL_MAINCLASS:      build.tools.commentchecker.CommentChecker
> BUILDTOOL_JAR_FILE: /Users/karnaukhovv/projects/jdk8-open/build/macosx-x86_64/btjars/commentchecker.jar
> =========================================================
> make: *** compile_font_config: No such file or directory.  Stop.
> make[3]: *** [all] Error 1
> make[2]: *** [all] Error 1
> make[1]: *** [jdk-build] Error 2
> make: *** [build_product_image] Error 2
>
> Regards,
> - Vlad
>
>>
>> although the quick-fix would be easy - to remove "  compile_font_config
>> " line from jdk/make/tools/Makefile... But need deeper investigations on
>> my side, as on linux my build really passed:(
>>
>>
>> Thank you one more times for sticking with this!
>>
>> J .
>>



From gnu.andrew at redhat.com  Mon Apr  8 17:04:31 2013
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 8 Apr 2013 13:04:31 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Fwd: requesting bug id for removing redundant
 fontconfig files
In-Reply-To: <51628CFC.1000001@redhat.com>
References: <515AC276.6010407@redhat.com>
	<165205663.831220.1365000140343.JavaMail.root@redhat.com>
	<5162792B.8080706@redhat.com> <51628955.60905@oracle.com>
	<51628CFC.1000001@redhat.com>
Message-ID: <1008691418.770380.1365440671054.JavaMail.root@redhat.com>

----- Original Message -----
> On 04/08/2013 11:09 AM, Erik Joelsson wrote:
> >  From a build point of view I think the patch looks ok. I can't comment on
> >  if it's safe to remove
> > the fontconfig files though. I've created a bug:
> >
> > 8011693: Remove redundant fontconfig files
> >
> 
> Thank you very much. I will continue review on 2d-dev.
> 

You have a review from me and a bug ID, so should be good to go.  The AWT developers
have expressed before that they don't expect fontconfig files to be used even in 7
and have had ample opportunity to object.

> J.
> 
> >
> > On 2013-04-08 10:00, Jiri Vanek wrote:
> >> On 04/03/2013 04:42 PM, Andrew Hughes wrote:
> >>> [Forwarding to 2d-dev]
> >>>
> >>> ----- Forwarded Message -----
> >>>> Hi!
> >>>>
> >>>> FontConfig  files are no longer necessary for jdk7 and 8. I have patch
> >>>> for
> >>>> their removal
> >>>> (http://jvanek.fedorapeople.org/oracle/jdk8/webrevs/removedFontConfigFiles/)
> >>>> and I have built and
> >>>> tested - looks ok.
> >>>> This approach was recommended at -
> >>>> http://mail.openjdk.java.net/pipermail/2d-dev/2012-May/002547.html.
> >>>>
> >>>> To move forward with this issue I would like to have  bug id if
> >>>> possible.
> >>>> Later I would like to
> >>>> backport this also to JDK7.\
> >>>>
> >>>> With kind regards
> >>>> Jiri Vanek
> >>>>
> >>>>
> >>>
> >>> This looks ok to me.  I assume it builds?
> >>
> >> sure :)
> >>
> >>>
> >>> There seems to generally be a lot of dead code in the jdk repository,
> >>> which is
> >>> very confusing for fixing anything.  Glad to see some of it going.
> >>>
> >>> Let's get it into 8 first, then we can backport to 7.  Oracle, can we
> >>> have a bug ID please?
> >>>
> >> Trying my luck with build-dev at openjdk.java.net....
> >>
> >> J.
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From james.graham at oracle.com  Mon Apr  8 21:19:16 2013
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 08 Apr 2013 14:19:16 -0700
Subject: [OpenJDK 2D-Dev]  [8] Request for review: 8000629
 [macosx] Blurry rendering with Java 7 on Retina display
In-Reply-To: <5162C1BD.8070703@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com> <5162C1BD.8070703@oracle.com>
Message-ID: <51633454.9060005@oracle.com>

Hi Sergey,

Did you check for possible performance hits for the new transform save/compare code in BufferedContext?  That is significantly more work per validate().  Also, isn't this case only used in the case where the caller specified a null xform in the argument list?  Does that happen (or, I guess, how does it happen) on a scaled graphics?

Something I didn't notice before - you adjust the max texture sizes in CGLGraphicsConfig by the device scale, but you adjust them by "getScaleFactor() * 2".  Why the "* 2"?  Shouldn't adjusting them by the scale factor itself be enough?  In the unscaled case, are our max textures sizes now half of what they used to be?  Also, where is this code used from?  Are there cases where an unscaled texture is planned and so the divide by the scale factor is unnecessarily conservative (as opposed to cases like back buffer allocation where the texture may be @2x...)

You removed a call to flushOnScreenGraphics in LWWindowPeer.  Was that just being paranoid before and really isn't needed?

It's already done and the code is written, but in retrospect, I'm not sure how much the optimizations in getTransform/setTransform are worth compared to the easy readability of having the transforms done linearly in a LIFO manner, such as:

setTransform:
	transform.setToIdentity();
	if (cX|cY != 0) { transform.translate(cX, cY); }
	if (dS != 1) transform.scale(dS, dS); }
	transform.concatenate(Tx);
getTransform:
	tx = new AT(transform);
	if (dS != 1) { tx.scale(invDs, invDs); }
	if (cX|cY != 0) { tx.translate(-cX, -cY); }
	return tx;

(I don't think it should be changed, but I'm throwing it out there as food for thought as it may be easier to maintain in the future, but it could also change the performance as I'm just speculating from how I remember the optimizations work...)

			...jim

On 4/8/2013 6:10 AM, Sergey Bylokhov wrote:
> Hi, Phil, JIm.
> New version of the fix:
> http://cr.openjdk.java.net/~serb/8000629/webrev.08
>   - Assumption that we should scale all native surfaces was wrong. In case of managed Bufferedimage we shouldn't scale native surface, because they are copies 1-1.(CGLSurfaceData.java:60).
>   - BufferedContext is not always updates current Paint, because it checks transX/transY from sg2d, which is not maintained in the scale mode.
> Test: FillTexturePaint.java
>
> Also I found a problem in the sg2d.getTransform(), where invScale does not apply to constrainX/Y.
> Test: TransformSetGet.java
>
> On 4/5/13 10:00 PM, Phil Race wrote:
>> SFAIK you haven't fixed the problem with TexturePaint I pointed out last week.
>> That needs to be fixed before you push.
>>
>> -phil.
>>
>> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>>> Hi, Jim.
>>> I assume, that you haven't additional comments? Can I consider you as the second reviewer?
>>> Note that I plan push it to awt-dev because, my other fixes depend on it.
>>>
>>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>>> Hello,
>>>> Please review the fix for jdk 8.
>>>> Change adds initial support of hidpi(mostly on 2d side). In the fix scale was added to the surface data/CGraphicsDevice /CGLLayer. This scale factor maps virtual coordinates to physical pixels.
>>>> This change doesn't add support of hidpi to aqua l&f and doesn't add support of dynamic change of scale factor.
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>>> --
>>>> Best regards, Sergey.
>>>
>>>
>>> --
>>> Best regards, Sergey.
>>
>
>
> --
> Best regards, Sergey.
>


From james.graham at oracle.com  Mon Apr  8 21:37:55 2013
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 08 Apr 2013 14:37:55 -0700
Subject: [OpenJDK 2D-Dev]  [8] Request for review: 8000629
 [macosx] Blurry rendering with Java 7 on Retina display
In-Reply-To: <51633454.9060005@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com> <5162C1BD.8070703@oracle.com>
	<51633454.9060005@oracle.com>
Message-ID: <516338B3.6020407@oracle.com>

I just wanted to add:

On 4/8/2013 2:19 PM, Jim Graham wrote:
> It's already done and the code is written, but in retrospect, I'm not sure how much the optimizations in getTransform/setTransform are worth compared to the easy readability of having the transforms done linearly in a LIFO manner, such as:
>
> setTransform:
>      transform.setToIdentity();
>      if (cX|cY != 0) { transform.translate(cX, cY); }
>      if (dS != 1) transform.scale(dS, dS); }
>      transform.concatenate(Tx);
> getTransform:
>      tx = new AT(transform);
>      if (dS != 1) { tx.scale(invDs, invDs); }
>      if (cX|cY != 0) { tx.translate(-cX, -cY); }
>      return tx;
>
> (I don't think it should be changed, but I'm throwing it out there as food for thought as it may be easier to maintain in the future, but it could also change the performance as I'm just speculating from how I remember the optimizations work...)

I had a sudden "uh oh" about the commutativity of the operations done in setTransform/getTransform (the ones in the webrev), but I just ran the math and it does appear to be a correct inverse operation (probably because it is a uniform scale and a translate which are more benign than other matrix ops).  So, there's a double check on the new math...

			...jim


From Sergey.Bylokhov at oracle.com  Tue Apr  9 09:54:28 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 09 Apr 2013 13:54:28 +0400
Subject: [OpenJDK 2D-Dev]  [8] Request for review: 8000629
 [macosx] Blurry rendering with Java 7 on Retina display
In-Reply-To: <51633454.9060005@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com> <5162C1BD.8070703@oracle.com>
	<51633454.9060005@oracle.com>
Message-ID: <5163E554.7050200@oracle.com>

Hi, Jim.
On 4/9/13 1:19 AM, Jim Graham wrote:
> Hi Sergey,
>
> Did you check for possible performance hits for the new transform 
> save/compare code in BufferedContext?
I am not sure how it can be improved, because BufferedPaints.setPaint() 
depends from the current transform of the sg2d.transform. And it should 
be called, when sg2d.transform is changed.
> That is significantly more work per validate(). 
I guess in most common case only aftm.equals() was added.
> Also, isn't this case only used in the case where the caller specified 
> a null xform in the argument list?  Does that happen (or, I guess, how 
> does it happen) on a scaled graphics?
Yes this happens if xform is null, so only code under if (xform == 
null)  was changed.
>
> Something I didn't notice before - you adjust the max texture sizes in 
> CGLGraphicsConfig by the device scale, but you adjust them by 
> "getScaleFactor() * 2".  Why the "* 2"?
This is related to 7160609. The problem was in fact, that we create huge 
texture during window initialization. In the fix I change this logic to 
use GL_MAX_TEXTURE_SIZE/2.
Separate CR:8010999 was created to track it.
>
> You removed a call to flushOnScreenGraphics in LWWindowPeer.  Was that 
> just being paranoid before and really isn't needed?
Now it is called not only when the window is resized, but when the 
surface is replaced. It was moved to replaceSurfaceData.
>
> It's already done and the code is written, but in retrospect, I'm not 
> sure how much the optimizations in getTransform/setTransform are worth 
> compared to the easy readability of having the transforms done 
> linearly in a LIFO manner, such as:
>
> setTransform:
>     transform.setToIdentity();
>     if (cX|cY != 0) { transform.translate(cX, cY); }
>     if (dS != 1) transform.scale(dS, dS); }
>     transform.concatenate(Tx);
> getTransform:
>     tx = new AT(transform);
>     if (dS != 1) { tx.scale(invDs, invDs); }
>     if (cX|cY != 0) { tx.translate(-cX, -cY); }
>     return tx;
>
> (I don't think it should be changed, but I'm throwing it out there as 
> food for thought as it may be easier to maintain in the future, but it 
> could also change the performance as I'm just speculating from how I 
> remember the optimizations work...)
When it was written, I was impressed by a code in the 2D.
>
>             ...jim
>
> On 4/8/2013 6:10 AM, Sergey Bylokhov wrote:
>> Hi, Phil, JIm.
>> New version of the fix:
>> http://cr.openjdk.java.net/~serb/8000629/webrev.08
>>   - Assumption that we should scale all native surfaces was wrong. In 
>> case of managed Bufferedimage we shouldn't scale native surface, 
>> because they are copies 1-1.(CGLSurfaceData.java:60).
>>   - BufferedContext is not always updates current Paint, because it 
>> checks transX/transY from sg2d, which is not maintained in the scale 
>> mode.
>> Test: FillTexturePaint.java
>>
>> Also I found a problem in the sg2d.getTransform(), where invScale 
>> does not apply to constrainX/Y.
>> Test: TransformSetGet.java
>>
>> On 4/5/13 10:00 PM, Phil Race wrote:
>>> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
>>> last week.
>>> That needs to be fixed before you push.
>>>
>>> -phil.
>>>
>>> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>>>> Hi, Jim.
>>>> I assume, that you haven't additional comments? Can I consider you 
>>>> as the second reviewer?
>>>> Note that I plan push it to awt-dev because, my other fixes depend 
>>>> on it.
>>>>
>>>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk 8.
>>>>> Change adds initial support of hidpi(mostly on 2d side). In the 
>>>>> fix scale was added to the surface data/CGraphicsDevice /CGLLayer. 
>>>>> This scale factor maps virtual coordinates to physical pixels.
>>>>> This change doesn't add support of hidpi to aqua l&f and doesn't 
>>>>> add support of dynamic change of scale factor.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Tue Apr  9 12:40:47 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 09 Apr 2013 16:40:47 +0400
Subject: [OpenJDK 2D-Dev]  [8] Request for review: 8000629
 [macosx] Blurry rendering with Java 7 on Retina display
In-Reply-To: <51633454.9060005@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com> <5162C1BD.8070703@oracle.com>
	<51633454.9060005@oracle.com>
Message-ID: <51640C4F.1090902@oracle.com>

Hi, Jim.
During additional testing I found some artifacts in some animation, when 
the rendering to the scaled VolatileImge is different from the non 
scaled variant. Can you please take a look to the CR:8011764.

On 4/9/13 1:19 AM, Jim Graham wrote:
> Hi Sergey,
>
> Did you check for possible performance hits for the new transform 
> save/compare code in BufferedContext?  That is significantly more work 
> per validate().  Also, isn't this case only used in the case where the 
> caller specified a null xform in the argument list? Does that happen 
> (or, I guess, how does it happen) on a scaled graphics?
>
> Something I didn't notice before - you adjust the max texture sizes in 
> CGLGraphicsConfig by the device scale, but you adjust them by 
> "getScaleFactor() * 2".  Why the "* 2"?  Shouldn't adjusting them by 
> the scale factor itself be enough?  In the unscaled case, are our max 
> textures sizes now half of what they used to be?  Also, where is this 
> code used from?  Are there cases where an unscaled texture is planned 
> and so the divide by the scale factor is unnecessarily conservative 
> (as opposed to cases like back buffer allocation where the texture may 
> be @2x...)
>
> You removed a call to flushOnScreenGraphics in LWWindowPeer.  Was that 
> just being paranoid before and really isn't needed?
>
> It's already done and the code is written, but in retrospect, I'm not 
> sure how much the optimizations in getTransform/setTransform are worth 
> compared to the easy readability of having the transforms done 
> linearly in a LIFO manner, such as:
>
> setTransform:
>     transform.setToIdentity();
>     if (cX|cY != 0) { transform.translate(cX, cY); }
>     if (dS != 1) transform.scale(dS, dS); }
>     transform.concatenate(Tx);
> getTransform:
>     tx = new AT(transform);
>     if (dS != 1) { tx.scale(invDs, invDs); }
>     if (cX|cY != 0) { tx.translate(-cX, -cY); }
>     return tx;
>
> (I don't think it should be changed, but I'm throwing it out there as 
> food for thought as it may be easier to maintain in the future, but it 
> could also change the performance as I'm just speculating from how I 
> remember the optimizations work...)
>
>             ...jim
>
> On 4/8/2013 6:10 AM, Sergey Bylokhov wrote:
>> Hi, Phil, JIm.
>> New version of the fix:
>> http://cr.openjdk.java.net/~serb/8000629/webrev.08
>>   - Assumption that we should scale all native surfaces was wrong. In 
>> case of managed Bufferedimage we shouldn't scale native surface, 
>> because they are copies 1-1.(CGLSurfaceData.java:60).
>>   - BufferedContext is not always updates current Paint, because it 
>> checks transX/transY from sg2d, which is not maintained in the scale 
>> mode.
>> Test: FillTexturePaint.java
>>
>> Also I found a problem in the sg2d.getTransform(), where invScale 
>> does not apply to constrainX/Y.
>> Test: TransformSetGet.java
>>
>> On 4/5/13 10:00 PM, Phil Race wrote:
>>> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
>>> last week.
>>> That needs to be fixed before you push.
>>>
>>> -phil.
>>>
>>> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>>>> Hi, Jim.
>>>> I assume, that you haven't additional comments? Can I consider you 
>>>> as the second reviewer?
>>>> Note that I plan push it to awt-dev because, my other fixes depend 
>>>> on it.
>>>>
>>>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk 8.
>>>>> Change adds initial support of hidpi(mostly on 2d side). In the 
>>>>> fix scale was added to the surface data/CGraphicsDevice /CGLLayer. 
>>>>> This scale factor maps virtual coordinates to physical pixels.
>>>>> This change doesn't add support of hidpi to aqua l&f and doesn't 
>>>>> add support of dynamic change of scale factor.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.



From bourges.laurent at gmail.com  Tue Apr  9 13:02:17 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Tue, 9 Apr 2013 15:02:17 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory
	enhancements
Message-ID: 

Dear Java2D members,

Could someone review the following webrev concerning Java2D Pisces to
enhance its performance and reduce its memory footprint (RendererContext
stored in thread local or concurrent queue):
http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/

FYI I fixed file headers in this patch and signed my OCA 3 weeks ago.

Remaining work:
- cleanup (comments ...)
- statistics to perform auto-tuning
- cache / memory cleanup (SoftReference ?): use hints or System properties
to adapt it to use cases
- another problem: fix clipping performance in Dasher / Stroker for
segments out of bounds

Could somebody support me ? ie help me working on these tasks or just to
discuss on Pisces algorithm / implementation ?

Best regards,
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From james.graham at oracle.com  Tue Apr  9 17:14:23 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 09 Apr 2013 10:14:23 -0700
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: 
References: 
Message-ID: <51644C6F.1070404@oracle.com>

Hi Laurent,

Quick questions - which benchmarks were run before/after?  I see a lot of benchmark running in your Pisces improvement thread, but but none here.

Also, this should be tested on multiple platforms, preferably Linux, Windows and Mac to see how it is affected by differences in the platform runtimes and threading (hopefully minimal).

Finally, Hotspot is supposed to deal very well for small thread-local allocations like the int[4] and Rectangle2D that you optimized.  Was it necessary to cache those at all?  I'm sure the statistics for the allocations show up in a memory profile, but that doesn't mean it is costing us anything - ideally such small allocations are as fast as free and having to deal with caching them in a context will actually lose performance.  It may be that the tile caching saved enough that it might have masked unnecessary or detrimental changes for the smaller objects...

			...jim

On 4/5/2013 5:20 AM, Laurent Bourg?s wrote:
> Dear java2d members,
>
> I figured out some troubles in java2d.pipe.AAShapePipe related to both concurrency & memory usage:
> - concurrency issue related to static theTile field: only 1 tile is cached so a new byte[] is created for other threads at each call to renderTile()
> - excessive memory usage (byte[] for tile, int[] and rectangle): at each call to renderPath / renderTiles, several small objects are created (never cached) that leads to hundreds megabytes that GC must deal with
>
> Here are profiling screenshots:
> - 4 threads drawing on their own buffered image (MapBench test):
> http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_byte_tile.png
>
> - excessive int[] / Rectangle creation:
> http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_int_bbox.png
> http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_rectangle_bbox.png
>
> Here is the proposed patch:
> http://jmmc.fr/~bourgesl/share/AAShapePipe/webrev-1/
>
> I applied a simple solution = use a ThreadLocal or ConcurrentLinkedQueue (see useThreadLocal flag) to cache one AAShapePipeContext per thread (2K max).
> As its memory footprint is very small, I recommend using ThreadLocal.
>
> Is it necessary to use Soft/Weak reference to avoid excessive memory usage for such cache ?
>
> Is there any class dedicated to such cache (ThreadLocal with cache eviction or ConcurrentLinkedQueue using WeakReference ?) ?
> I think it could be very useful at the JDK level to have such feature (ie a generic "GC friendly"cache )
>
> Regards,
> Laurent


From james.graham at oracle.com  Tue Apr  9 17:15:59 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 09 Apr 2013 10:15:59 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: 
References: 
	
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	
	<51549C3F.1020301@oracle.com>
	
	<5154ACCD.5090105@oracle.com>
	
	
	
	
	
	
Message-ID: <51644CCF.3000603@oracle.com>

Hi Laurent,

I haven't looked at the changes in depth yet, but I wanted to echo my comments on the AAShapePipe thread - make sure you do benchmark testing on multiple platforms and double check if caching small objets actually helps anything (otherwise it is unnecessary code complexity and possibly a detrimental change given that Hotspot optimizes small object allocation so much)...

			...jim

On 4/1/2013 2:20 PM, Laurent Bourg?s wrote:
> Andra & Jim,
>
> Here is the current status of my patch alpha version:
> http://jmmc.fr/~bourgesl/share/java2d-pisces/
>
> There is still a lot to be done: clean-up, stats, pisces class instance recycling (renderer, stroker ...) and of course sizing correctly initial arrays (dirty or clean) in the RendererContext (thread local storage).
> For performance reasons, I am using now RendererContext members first (cache for rowAARLE for example) before using ArrayCaches (dynamic arrays).
>
> I provided the patch as zip file and few benchmark using Andrea's MapBench (Xmx128m):
> - OpenJDK 8 PATCHED:
> Testing file /home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser
> 1 threads and 20 loops per thread, time: 3687 ms
> 2 threads and 20 loops per thread, time: 3693 ms
> 4 threads and 20 loops per thread, time: 6849 ms
>
> Loading drawing commands from file: /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
> Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213}
> Testing file /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
> 1 threads and 20 loops per thread, time: 27266 ms
> 2 threads and 20 loops per thread, time: 33628 ms
> 4 threads and 20 loops per thread, time: 61577 ms
>
> - OpenJDK 8 REFERENCE:
> Testing file /home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser
> 1 threads and 20 loops per thread, time: 3982 ms
> 2 threads and 20 loops per thread, time: 4852 ms
> 4 threads and 20 loops per thread, time: 8842 ms
>
> Loading drawing commands from file: /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
> Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213}
> Testing file /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
> 1 threads and 20 loops per thread, time: 55889 ms
> 2 threads and 20 loops per thread, time: 77691 ms
> 4 threads and 20 loops per thread, time: 141981 ms
>
> - Oracle JDK8 DUCTUS:
> Testing file /home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser
> 1 threads and 20 loops per thread, time: 1894 ms
> 2 threads and 20 loops per thread, time: 3905 ms
> 4 threads and 20 loops per thread, time: 7485 ms
>
> Loading drawing commands from file: /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
> Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213}
> Testing file /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
> 1 threads and 20 loops per thread, time: 20911 ms
> 2 threads and 20 loops per thread, time: 39297 ms
> 4 threads and 20 loops per thread, time: 103392 ms
>
> As you can see, patched openJdk8 performs better and it is very noticeable on big drawings (dc_shp_alllayers_2013-00-30-07-00-47.ser) and better than ductus with 2 threads !!
>
> Laurent
>
>
> 2013/3/30 Andrea Aime >
>
>     On Sat, Mar 30, 2013 at 2:01 PM, Laurent Bourg?s > wrote:
>
>         - clipping issues (dasher, stroker) and spatial resolution (no cpu/memory waste)
>
>
>     I see, yes. Indeed in the GeoServer code we already work around some of those issues by
>     clipping the geometries read from the database to the graphics2d viewport before giving them
>     to the renderer, we had to do that both for performance issues and to avoid OOM errors
>     when basic stroke with dasharray is used against a line that is many times longer than the
>     current display area
>
>             I don't have anything ready, the existing code loads data from spatial database, sets up styles from XML descriptions, turns each spatial db geomety in java shapes
>             and so on. But I guess I could concoct something close enough.
>             I'm writing some code to gather statistics about the shapes that are actually painted (scrolling over the path iterators) and then I'll try to make a randomized
>             shape painter that gets close to those stats.
>
>
>         Great news ! I am waiting your test code to perform few benchmarks.
>
>         I am using J2DBench but it does not perform such complex drawing (complex shapes ...) or multi threading tests (parallel drawings on buffered images)
>
>
>     Ok, I've created a "MapBench" by serializing shapes, strokes and fills from a real GeoServer instance to disk, and have them
>     play in a simple multithreaded test harness.
>     What you get in the output is not exactly the maps generated by GeoServer since we use a number of tricks to speed up rendering,
>     including painting over multiple drawing surfaces (the serializer only handles one), also, some maps have text showing up because
>     in order to pain "labels along a line" we actually turn the chars into shapes and place them along the line, but those labels that we
>     can predict are "straight" are painted with drawGlyphVector so they won't show up (haven't built a serialization for that case).
>
>     Regardless, the test should be good enough to test both performance and scalability.
>     Here is the package: http://demo.geo-solutions.it/share/mapbench.zip
>
>     It contains:
>     * ShapeDumpingGraphics2D, a Graphics2D wrapper writing on disk all draw(Shape) and
>        fill(Shape) commands issued to it
>     * A bunch of *.ser files, that are the serialized drawing command sequences
>     * A bunch of *.png files, which are the rendered versions of the .ser files (for reference)
>     * MapDisplay, which reads all *.ser files from a directory and displays them in JFrame and
>         generates the .png files as well
>     * MapBench, which reads all *.ser files from a directory and repeatedly paints them in a loop
>        with a growing number of threads
>     * Two txt files with the timings of the benchmarks on my machine for Oracle JDK 7 and
>         OpenJDK 7, here is an example comparison:
>
>     OpenJDK7:
>     Testing file /tmp/dc_boulder_2013-13-30-06-13-17.ser
>     1 threads and 20 loops per thread, time: 3340 ms
>     2 threads and 20 loops per thread, time: 3688 ms
>     4 threads and 20 loops per thread, time: 4665 ms
>     8 threads and 20 loops per thread, time: 7343 ms
>
>     Oracle JDK 7:
>     Warm up took 29516 ms
>     Testing file /tmp/dc_boulder_2013-13-30-06-13-17.ser
>     1 threads and 20 loops per thread, time: 1754 ms
>     2 threads and 20 loops per thread, time: 2878 ms
>     4 threads and 20 loops per thread, time: 6792 ms
>     8 threads and 20 loops per thread, time: 14275 ms
>
>     As you can see ductus is significantly faster than pisces, but it has serious scalability
>     issues, while pisces scales up a lot better.
>
>     The code has been put together in a haste, sorry for the lack of comments, hopefully it is
>     simple enough that it's usable anyways.
>
>     Cheers
>     Andrea
>
>
>     --
>     ==
>     Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.
>     ==
>
>     Ing. Andrea Aime
>     @geowolf
>     Technical Lead
>
>     GeoSolutions S.A.S.
>     Via Poggio alle Viti 1187
>     55054  Massarosa (LU)
>     Italy
>     phone: +39 0584 962313
>     fax: +39 0584 1660272
>     mob: +39  339 8844549
>
>     http://www.geo-solutions.it
>     http://twitter.com/geosolutions_it
>
>     -------------------------------------------------------
>
>


From bourges.laurent at gmail.com  Tue Apr  9 17:34:48 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Tue, 9 Apr 2013 19:34:48 +0200
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: <51644C6F.1070404@oracle.com>
References: 
	<51644C6F.1070404@oracle.com>
Message-ID: 

Dear Jim,

I advocated I only looked at the netbeans memory profiler's output: no more
megabytes allocated !

The main question is: how to know how GC / hotspot deals with such small
allocations ? Is there any JVM flag to enable to see real allocations as
does jmap -histo.

>
> Quick questions - which benchmarks were run before/after?  I see a lot of
> benchmark running in your Pisces improvement thread, but but none here.
>

Agreed; I can try running j2dBench on this fix only. I generally run
Andrea's MapBench as I appeared more complex and using multiple threads.


> Also, this should be tested on multiple platforms, preferably Linux,
> Windows and Mac to see how it is affected by differences in the platform
> runtimes and threading (hopefully minimal).
>

It appears more difficult for me: I can use at work a mac 10.8 and I can
run Windows XP within virtual box (but it is not very representative).

Don't you have at oracle any test platform to perform such tests /
benchmark ?


> Finally, Hotspot is supposed to deal very well for small thread-local
> allocations like the int[4] and Rectangle2D that you optimized.  Was it
> necessary to cache those at all?  I'm sure the statistics for the
> allocations show up in a memory profile, but that doesn't mean it is
> costing us anything - ideally such small allocations are as fast as free
> and having to deal with caching them in a context will actually lose
> performance.  It may be that the tile caching saved enough that it might
> have masked unnecessary or detrimental changes for the smaller objects...


I repeat my question: how can I know at runtime how hotspot optimizes
AAShapePipe code (allocations ...) ? Does hotspot can do stack allocation ?
is it explained somewhere (allocation size threshold) ?

Maybe verbose:gc output may help ?

Finally I spent a lot of time on pisces renderer and running MapBench to
show performance gains.

Thanks for your interesting feedback,

Laurent

On 4/5/2013 5:20 AM, Laurent Bourg?s wrote:

> Dear java2d members,
>
> I figured out some troubles in java2d.pipe.AAShapePipe related to both
> concurrency & memory usage:
> - concurrency issue related to static theTile field: only 1 tile is cached
> so a new byte[] is created for other threads at each call to renderTile()
> - excessive memory usage (byte[] for tile, int[] and rectangle): at each
> call to renderPath / renderTiles, several small objects are created (never
> cached) that leads to hundreds megabytes that GC must deal with
>
> Here are profiling screenshots:
> - 4 threads drawing on their own buffered image (MapBench test):
> http://jmmc.fr/~bourgesl/**share/AAShapePipe/AAShapePipe_**byte_tile.png
>
> - excessive int[] / Rectangle creation:
> http://jmmc.fr/~bourgesl/**share/AAShapePipe/AAShapePipe_**int_bbox.png
> http://jmmc.fr/~bourgesl/**share/AAShapePipe/AAShapePipe_**
> rectangle_bbox.png
>
> Here is the proposed patch:
> http://jmmc.fr/~bourgesl/**share/AAShapePipe/webrev-1/
>
> I applied a simple solution = use a ThreadLocal or ConcurrentLinkedQueue
> (see useThreadLocal flag) to cache one AAShapePipeContext per thread (2K
> max).
> As its memory footprint is very small, I recommend using ThreadLocal.
>
> Is it necessary to use Soft/Weak reference to avoid excessive memory usage
> for such cache ?
>
> Is there any class dedicated to such cache (ThreadLocal with cache
> eviction or ConcurrentLinkedQueue using WeakReference ?) ?
> I think it could be very useful at the JDK level to have such feature (ie
> a generic "GC friendly"cache )
>
> Regards,
> Laurent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From james.graham at oracle.com  Tue Apr  9 17:44:43 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 09 Apr 2013 10:44:43 -0700
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: 
References: 
	<51644C6F.1070404@oracle.com>
	
Message-ID: <5164538B.9080804@oracle.com>

Hi Laurent,

The allocations will always show up on a heap profiler, I don't know of any way of having them not show up if they are stack allocated, but I don't think that stack allocation is the issue here - small allocations come out of a fast generation that costs almost nothing to allocate from and nearly nothing to clean up.  They are actually getting allocated and GC'd, but the process is optimized.

The only way to tell is to benchmark and see which changes make a difference and which are in the noise (or, in some odd counter-intuitive cases, counter-productive)...

			...jim

On 4/9/2013 10:34 AM, Laurent Bourg?s wrote:
> Dear Jim,
>
> I advocated I only looked at the netbeans memory profiler's output: no more megabytes allocated !
>
> The main question is: how to know how GC / hotspot deals with such small allocations ? Is there any JVM flag to enable to see real allocations as does jmap -histo.
>
>
>     Quick questions - which benchmarks were run before/after?  I see a lot of benchmark running in your Pisces improvement thread, but but none here.
>
>
> Agreed; I can try running j2dBench on this fix only. I generally run Andrea's MapBench as I appeared more complex and using multiple threads.
>
>     Also, this should be tested on multiple platforms, preferably Linux, Windows and Mac to see how it is affected by differences in the platform runtimes and threading (hopefully minimal).
>
>
> It appears more difficult for me: I can use at work a mac 10.8 and I can run Windows XP within virtual box (but it is not very representative).
>
> Don't you have at oracle any test platform to perform such tests / benchmark ?
>
>     Finally, Hotspot is supposed to deal very well for small thread-local allocations like the int[4] and Rectangle2D that you optimized.  Was it necessary to cache those at all?  I'm sure the statistics for the allocations show up in a memory profile, but that doesn't mean it is costing us anything - ideally such small allocations are as fast as free and having to deal with caching them in a context will actually lose performance.  It may be that the tile caching saved enough that it might have masked unnecessary or detrimental changes for the smaller objects...
>
>
> I repeat my question: how can I know at runtime how hotspot optimizes AAShapePipe code (allocations ...) ? Does hotspot can do stack allocation ? is it explained somewhere (allocation size threshold) ?
>
> Maybe verbose:gc output may help ?
>
> Finally I spent a lot of time on pisces renderer and running MapBench to show performance gains.
>
> Thanks for your interesting feedback,
>
> Laurent
>
> On 4/5/2013 5:20 AM, Laurent Bourg?s wrote:
>
>     Dear java2d members,
>
>     I figured out some troubles in java2d.pipe.AAShapePipe related to both concurrency & memory usage:
>     - concurrency issue related to static theTile field: only 1 tile is cached so a new byte[] is created for other threads at each call to renderTile()
>     - excessive memory usage (byte[] for tile, int[] and rectangle): at each call to renderPath / renderTiles, several small objects are created (never cached) that leads to hundreds megabytes that GC must deal with
>
>     Here are profiling screenshots:
>     - 4 threads drawing on their own buffered image (MapBench test):
>     http://jmmc.fr/~bourgesl/__share/AAShapePipe/AAShapePipe___byte_tile.png 
>
>     - excessive int[] / Rectangle creation:
>     http://jmmc.fr/~bourgesl/__share/AAShapePipe/AAShapePipe___int_bbox.png 
>     http://jmmc.fr/~bourgesl/__share/AAShapePipe/AAShapePipe___rectangle_bbox.png 
>
>     Here is the proposed patch:
>     http://jmmc.fr/~bourgesl/__share/AAShapePipe/webrev-1/ 
>
>     I applied a simple solution = use a ThreadLocal or ConcurrentLinkedQueue (see useThreadLocal flag) to cache one AAShapePipeContext per thread (2K max).
>     As its memory footprint is very small, I recommend using ThreadLocal.
>
>     Is it necessary to use Soft/Weak reference to avoid excessive memory usage for such cache ?
>
>     Is there any class dedicated to such cache (ThreadLocal with cache eviction or ConcurrentLinkedQueue using WeakReference ?) ?
>     I think it could be very useful at the JDK level to have such feature (ie a generic "GC friendly"cache )
>
>     Regards,
>     Laurent
>
>


From andrea.aime at geo-solutions.it  Wed Apr 10 08:01:22 2013
From: andrea.aime at geo-solutions.it (Andrea Aime)
Date: Wed, 10 Apr 2013 10:01:22 +0200
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: 
References: 
	<51644C6F.1070404@oracle.com>
	
Message-ID: 

On Tue, Apr 9, 2013 at 7:34 PM, Laurent Bourg?s
wrote:

> Also, this should be tested on multiple platforms, preferably Linux,
> Windows and Mac to see how it is affected by differences in the platform
> runtimes and threading (hopefully minimal).
>
> It appears more difficult for me: I can use at work a mac 10.8 and I can
> run Windows XP within virtual box (but it is not very representative).
>

I believe I can run MapBench on my Linux 64bit box during the next weekend,
that would add a platform, and one were the
server side behavior is enabled by default. And hopefully run the other
benchmark as well.

Laurent, have you made any changes to MapBench since I've sent it to you?

Cheers
Andrea


-- 
==
GeoServer training in Milan, 6th & 7th June 2013!  Visit
http://geoserver.geo-solutions.it for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bourges.laurent at gmail.com  Wed Apr 10 08:14:12 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Wed, 10 Apr 2013 10:14:12 +0200
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: 
References: 
	<51644C6F.1070404@oracle.com>
	
	
Message-ID: 

Andrea,
I am running benchmarks on my laptop (i7 - 2 core 2.8Ghz + HT => 4 virtual
cpus) on linux 64 (fedora 14).
Note: I always use cpufrequtils to set the cpu governor to performance and
use fixed frequency = 2.8Ghz:
[bourgesl at jmmc-laurent ~]$ uname -a
Linux jmmc-laurent.obs.ujf-grenoble.fr 2.6.35.14-106.fc14.x86_64 #1 SMP Wed
Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

2013/4/10 Andrea Aime 

> On Tue, Apr 9, 2013 at 7:34 PM, Laurent Bourg?s  > wrote:
>
>> Also, this should be tested on multiple platforms, preferably Linux,
>> Windows and Mac to see how it is affected by differences in the platform
>> runtimes and threading (hopefully minimal).
>>
>> It appears more difficult for me: I can use at work a mac 10.8 and I can
>> run Windows XP within virtual box (but it is not very representative).
>>
>
> I believe I can run MapBench on my Linux 64bit box during the next
> weekend, that would add a platform, and one were the
> server side behavior is enabled by default. And hopefully run the other
> benchmark as well.
>

I also run j2DBench but I can try also Java2D.demos to perform regression
tests.


>
> Laurent, have you made any changes to MapBench since I've sent it to you?
>

Yes I fixed a bit (cached BasicStroke, reused BufferedImage / Graphics) and
added explicit GC before tests (same initial conditions):
http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench/

Look at MapBench-src.zipfor
test changes.

Thanks for your efforts,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From andrea.aime at geo-solutions.it  Wed Apr 10 08:24:04 2013
From: andrea.aime at geo-solutions.it (Andrea Aime)
Date: Wed, 10 Apr 2013 10:24:04 +0200
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: 
References: 
	<51644C6F.1070404@oracle.com>
	
	
	
Message-ID: 

On Wed, Apr 10, 2013 at 10:14 AM, Laurent Bourg?s  wrote:

> Andrea,
> I am running benchmarks on my laptop (i7 - 2 core 2.8Ghz + HT => 4 virtual
> cpus) on linux 64 (fedora 14).
> Note: I always use cpufrequtils to set the cpu governor to performance and
> use fixed frequency = 2.8Ghz:
> [bourgesl at jmmc-laurent ~]$ uname -a
> Linux jmmc-laurent.obs.ujf-grenoble.fr 2.6.35.14-106.fc14.x86_64 #1 SMP
> Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
>
>
Yes, I did the same when I initially run the MapBench on JDK 7 vs OpenJDK 7
(governor settings wise).

Since you are already running on that platform, maybe I can try to cover
Linux 32 bit instead, I also have a notebook with that setup.


>> Laurent, have you made any changes to MapBench since I've sent it to you?
>>
>
> Yes I fixed a bit (cached BasicStroke, reused BufferedImage / Graphics)
> and added explicit GC before tests (same initial conditions):
> http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench/
>
> Look at MapBench-src.zipfor test changes.
>

Thanks

Cheers
Andrea

-- 
==
GeoServer training in Milan, 6th & 7th June 2013!  Visit
http://geoserver.geo-solutions.it for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bourges.laurent at gmail.com  Wed Apr 10 08:58:39 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Wed, 10 Apr 2013 10:58:39 +0200
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: <5164538B.9080804@oracle.com>
References: 
	<51644C6F.1070404@oracle.com>
	
	<5164538B.9080804@oracle.com>
Message-ID: 

Dear Jim,

2013/4/9 Jim Graham 

>
> The allocations will always show up on a heap profiler, I don't know of
> any way of having them not show up if they are stack allocated, but I don't
> think that stack allocation is the issue here - small allocations come out
> of a fast generation that costs almost nothing to allocate from and nearly
> nothing to clean up.  They are actually getting allocated and GC'd, but the
> process is optimized.
>
> The only way to tell is to benchmark and see which changes make a
> difference and which are in the noise (or, in some odd counter-intuitive
> cases, counter-productive)...
>
>                         ...jim
>

I advocate I like GC because it avoids in Java dealing with pointers like
C/C++ does; however, I prefer GC clean real garbage (application...) than
wasted memory:
I prefer not count on GC when I can avoid wasting memory that gives GC more
work = reduce useless garbage (save the planet) !

Moreover, GC and / or Thread local allocation (TLAB) seems to have more
overhead than you think = "fast generation that costs almost nothing to
allocate from and nearly nothing to clean up".

Here are my micro-benchmark results related to int[4] allocation where I
mimic the AAShapePipe.fillParallelogram() method:
   Patch Ref Gain  5,96 8,27 138,76%  7,31 14,96 204,65%  10,65 20,4 191,55%
15,44 29,83 193,20%
Test environment:
Linux64 with OpenJDK8 (2 real cpu cores, 4 virtual cpus)
JVM settings:
-XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal -Xms128m  -Xmx128m

Benchmark code (using Peter Levart microbench classes):
http://jmmc.fr/~bourgesl/share/AAShapePipe/microbench/

My conclusion is:  "nothing" > zero (allocation + cleanup) and it is very
noticeable in multi threading tests.

I advocate that I use a dirty int[4] array (no cleanup) but it is not
necessary : maybe the performance gain come from that reason.


Finally here is the output with  -XX:+PrintTLAB flag:
TLAB: gc thread: 0x00007f105813d000 [id: 4053] desired_size: 1312KB slow
allocs: 0  refill waste: 20992B alloc: 1,00000    65600KB refills: 20
waste  1,2% gc: 323712B slow: 600B fast: 0B
TLAB: gc thread: 0x00007f105813a800 [id: 4052] desired_size: 1312KB slow
allocs: 0  refill waste: 20992B alloc: 1,00000    65600KB refills: 7 waste
7,9% gc: 745568B slow: 176B fast: 0B
TLAB: gc thread: 0x00007f1058138800 [id: 4051] desired_size: 1312KB slow
allocs: 0  refill waste: 20992B alloc: 1,00000    65600KB refills: 15
waste  3,1% gc: 618464B slow: 448B fast: 0B
TLAB: gc thread: 0x00007f1058136800 [id: 4050] desired_size: 1312KB slow
allocs: 0  refill waste: 20992B alloc: 1,00000    65600KB refills: 7 waste
0,0% gc: 0B slow: 232B fast: 0B
TLAB: gc thread: 0x00007f1058009000 [id: 4037] desired_size: 1312KB slow
allocs: 0  refill waste: 20992B alloc: 1,00000    65600KB refills: 1 waste
27,5% gc: 369088B slow: 0B fast: 0B
TLAB totals: thrds: 5  refills: 50 max: 20 slow allocs: 0 max 0 waste:
3,1% gc: 2056832B max: 745568B slow: 1456B max: 600B fast: 0B max: 0B

I would have expected that TLAB can recycle all useless int[4] arrays as
fast as possible => waste = 100% ???

*Is there any bug in TLAB (core-libs) ?
Should I send such issue to hotspot team ?
*

*Test using ThreadLocal AAShapePipeContext:*
{
    AAShapePipeContext ctx = getThreadContext();
    int abox[] = ctx.abox;

    // use array:
    // mimic: AATileGenerator aatg = renderengine.getAATileGenerator(x, y,
dx1, dy1, dx2, dy2, 0, 0, clip, abox);
    abox[0] = 7;
    abox[1] = 11;
    abox[2] = 13;
    abox[3] = 17;

    // mimic: renderTiles(sg, computeBBox(ux1, uy1, ux2, uy2), aatg, abox);
    devNull1.yield(abox);

    if (!useThreadLocal) {
        restoreContext(ctx);
    }
}

-XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728
-XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal
-XX:+UseCompressedKlassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
>> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24]
#-------------------------------------------------------------
# ContextGetInt4: run duration: 10 000 ms
#
# Warm up:
#           4 threads, Tavg =     13,84 ns/op (? =   0,23 ns/op), Total ops
=   2889056179 [    13,93 (717199825),     13,87 (720665624),     13,48
(741390545),     14,09 (709800185)]
#           4 threads, Tavg =     14,25 ns/op (? =   0,57 ns/op), Total ops
=   2811615084 [    15,21 (658351236),     14,18 (706254551),     13,94
(718202949),     13,74 (728806348)]
cleanup (explicit Full GC) ...
cleanup done.
# Measure:
*1 threads, Tavg =      5,96 ns/op (? =   0,00 ns/op), Total ops =
1678357614 [     5,96 (1678357614)]
2 threads, Tavg =      7,33 ns/op (? =   0,03 ns/op), Total ops =
2729723450 [     7,31 (1369694121),      7,36 (1360029329)]
3 threads, Tavg =     10,65 ns/op (? =   2,73 ns/op), Total ops =
2817154340 [    13,24 (755190111),     13,23 (755920429),      7,66
(1306043800)]
**4 threads, Tavg =     15,44 ns/op (? =   3,33 ns/op), Total ops =
2589897733 [    17,05 (586353618),     19,23 (519345153),     17,88
(559401974),     10,81 *(924796988)]
#
<< JVM END

*Test using standard int[4] allocation:*
{
    int abox[] = new int[4];

      // use array:
    // mimic: AATileGenerator aatg = renderengine.getAATileGenerator(x, y,
dx1, dy1, dx2, dy2, 0, 0, clip, abox);
    abox[0] = 7;
    abox[1] = 11;
    abox[2] = 13;
    abox[3] = 17;

    // mimic: renderTiles(sg, computeBBox(ux1, uy1, ux2, uy2), aatg, abox);
    devNull1.yield(abox);
}

-XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728
-XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal
-XX:+UseCompressedKlassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
>> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24]
#-------------------------------------------------------------
# GetInt4: run duration: 10 000 ms
#
# Warm up:
#           4 threads, Tavg =     31,07 ns/op (? =   0,60 ns/op), Total ops
=   1287292142 [    30,26 (330475567),     31,92 (313328449),     31,27
(319805520),     30,89 (323682606)]
#           4 threads, Tavg =     30,94 ns/op (? =   0,33 ns/op), Total ops
=   1293000783 [    30,92 (323382193),     30,61 (326730340),     31,48
(317621402),     30,74 (325266848)]
cleanup (explicit Full GC) ...
cleanup done.
# Measure:
*1 threads, Tavg =      8,27 ns/op (? =   0,00 ns/op), Total ops =
1209213909 [     8,27 (1209213909)]
2 threads, Tavg =     14,96 ns/op (? =   0,04 ns/op), Total ops =
1337024734 [    15,00 (666659967),     14,92 (670364767)]
3 threads, Tavg =     20,40 ns/op (? =   1,03 ns/op), Total ops =
1470560922 [    21,21 (471592958),     19,00 (526302911),     21,16
(472665053)]
**4 threads, Tavg =     29,83 ns/op (? =   1,82 ns/op), Total ops =
1340065128 [    31,17 (320806983),     31,58 (316358130),     26,94
(370806790),     30,11 *(332093225)]
#
<< JVM END

Best regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bourges.laurent at gmail.com  Wed Apr 10 11:20:23 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Wed, 10 Apr 2013 13:20:23 +0200
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: <51653C56.1010306@gmail.com>
References: 
	<51644C6F.1070404@oracle.com>
	
	<5164538B.9080804@oracle.com>
	
	<51653C56.1010306@gmail.com>
Message-ID: 

Peter,

1/ I modified your TestRunner class to print total ops and perform explicit
GC before runTests:
http://jmmc.fr/~bourgesl/share/AAShapePipe/microbench/

2/ I applied your advice but it does not change much:

             -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728
-XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal
-XX:+UseCompressedKlassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
             >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM
25.0-b24]
             #-------------------------------------------------------------
             # ContextGetInt4: run duration: 10 000 ms
             #
             # Warm up:
             #           4 threads, Tavg =     13,84 ns/op (? =   0,23
ns/op), Total ops =   2889056179 [    13,93 (717199825),     13,87
(720665624),     13,48 (741390545),     14,09 (709800185)]
             #           4 threads, Tavg =     14,25 ns/op (? =   0,57
ns/op), Total ops =   2811615084 [    15,21 (658351236),     14,18
(706254551),     13,94 (718202949),     13,74 (728806348)]
             cleanup (explicit Full GC) ...
             cleanup done.
             # Measure:
             1 threads, Tavg =      5,96 ns/op (? =   0,00 ns/op), Total
ops =   1678357614 [     5,96 (1678357614)]
             2 threads, Tavg =      7,33 ns/op (? =   0,03 ns/op), Total
ops =   2729723450 [     7,31 (1369694121),      7,36 (1360029329)]
             3 threads, Tavg =     10,65 ns/op (? =   2,73 ns/op), Total
ops =   2817154340 [    13,24 (755190111),     13,23 (755920429),      7,66
(1306043800)]
             4 threads, Tavg =     15,44 ns/op (? =   3,33 ns/op), Total
ops =   2589897733 [    17,05 (586353618),     19,23 (519345153),     17,88
(559401974),     10,81 (924796988)]

             -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728
-XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal
-XX:-TieredCompilation -XX:+UseCompressedKlassPointers
-XX:+UseCompressedOops -XX:+UseParallelGC
             >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM
25.0-b24]
             #-------------------------------------------------------------
             # GetInt4: run duration: 10 000 ms
             #
             # Warm up:
             #           4 threads, Tavg =     31,56 ns/op (? =   0,43
ns/op), Total ops =   1267295706 [    31,30 (319512554),     31,02
(322293333),     32,12 (311334550),     31,82 (314155269)]
             #           4 threads, Tavg =     30,75 ns/op (? =   1,81
ns/op), Total ops =   1302123211 [    32,21 (310949394),     32,37
(309275124),     27,87 (359125007),     31,01 (322773686)]
             cleanup (explicit Full GC) ...
             cleanup done.
             # Measure:
             1 threads, Tavg =      8,36 ns/op (? =   0,00 ns/op), Total
ops =   1196238323 [     8,36 (1196238323)]
             2 threads, Tavg =     14,95 ns/op (? =   0,04 ns/op), Total
ops =   1337648720 [    15,00 (666813210),     14,91 (670835510)]
             3 threads, Tavg =     20,65 ns/op (? =   0,99 ns/op), Total
ops =   1453119707 [    19,57 (511100480),     21,97 (455262170),     20,54
(486757057)]
             4 threads, Tavg =     30,76 ns/op (? =   0,54 ns/op), Total
ops =   1301090278 [    31,51 (317527231),     30,79 (324921525),     30,78
(325063322),     29,99 (333578200)]
             #
             << JVM END

3/ I tried several heap settings: without Xms/Xmx ... but it has almost no
effect.

*Should I play with TLAB resize / initial size ? or different GC collector
(G1 ...) ?

Does anybody can explain me what PrintTLAB mean ?*

Laurent

2013/4/10 Peter Levart 

>  Hi Laurent,
>
> Could you disable tiered compilation for performance tests? Tiered
> compilation is usually a source of jitter in the results. Pass
> -XX:-TieredCompilation to the VM.
>
> Regards, Peter
>
>
>
> On 04/10/2013 10:58 AM, Laurent Bourg?s wrote:
>
>  Dear Jim,
>
> 2013/4/9 Jim Graham 
>
>>
>> The allocations will always show up on a heap profiler, I don't know of
>> any way of having them not show up if they are stack allocated, but I don't
>> think that stack allocation is the issue here - small allocations come out
>> of a fast generation that costs almost nothing to allocate from and nearly
>> nothing to clean up.  They are actually getting allocated and GC'd, but the
>> process is optimized.
>>
>> The only way to tell is to benchmark and see which changes make a
>> difference and which are in the noise (or, in some odd counter-intuitive
>> cases, counter-productive)...
>>
>>                         ...jim
>>
>
> I advocate I like GC because it avoids in Java dealing with pointers like
> C/C++ does; however, I prefer GC clean real garbage (application...) than
> wasted memory:
> I prefer not count on GC when I can avoid wasting memory that gives GC
> more work = reduce useless garbage (save the planet) !
>
> Moreover, GC and / or Thread local allocation (TLAB) seems to have more
> overhead than you think = "fast generation that costs almost nothing to
> allocate from and nearly nothing to clean up".
>
>  Here are my micro-benchmark results related to int[4] allocation where I
> mimic the AAShapePipe.fillParallelogram() method:
>   Patch Ref Gain  5,96 8,27 138,76%  7,31 14,96 204,65%  10,65 20,4
> 191,55%  15,44 29,83 193,20%
> Test environment:
> Linux64 with OpenJDK8 (2 real cpu cores, 4 virtual cpus)
> JVM settings:
> -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal -Xms128m  -Xmx128m
>
> Benchmark code (using Peter Levart microbench classes):
> http://jmmc.fr/~bourgesl/share/AAShapePipe/microbench/
>
> My conclusion is:  "nothing" > zero (allocation + cleanup) and it is very
> noticeable in multi threading tests.
>
> I advocate that I use a dirty int[4] array (no cleanup) but it is not
> necessary : maybe the performance gain come from that reason.
>
>
> Finally here is the output with  -XX:+PrintTLAB flag:
> TLAB: gc thread: 0x00007f105813d000 [id: 4053] desired_size: 1312KB slow
> allocs: 0  refill waste: 20992B alloc: 1,00000    65600KB refills: 20
> waste  1,2% gc: 323712B slow: 600B fast: 0B
> TLAB: gc thread: 0x00007f105813a800 [id: 4052] desired_size: 1312KB slow
> allocs: 0  refill waste: 20992B alloc: 1,00000    65600KB refills: 7 waste
> 7,9% gc: 745568B slow: 176B fast: 0B
> TLAB: gc thread: 0x00007f1058138800 [id: 4051] desired_size: 1312KB slow
> allocs: 0  refill waste: 20992B alloc: 1,00000    65600KB refills: 15
> waste  3,1% gc: 618464B slow: 448B fast: 0B
> TLAB: gc thread: 0x00007f1058136800 [id: 4050] desired_size: 1312KB slow
> allocs: 0  refill waste: 20992B alloc: 1,00000    65600KB refills: 7 waste
> 0,0% gc: 0B slow: 232B fast: 0B
> TLAB: gc thread: 0x00007f1058009000 [id: 4037] desired_size: 1312KB slow
> allocs: 0  refill waste: 20992B alloc: 1,00000    65600KB refills: 1 waste
> 27,5% gc: 369088B slow: 0B fast: 0B
> TLAB totals: thrds: 5  refills: 50 max: 20 slow allocs: 0 max 0 waste:
> 3,1% gc: 2056832B max: 745568B slow: 1456B max: 600B fast: 0B max: 0B
>
> I would have expected that TLAB can recycle all useless int[4] arrays as
> fast as possible => waste = 100% ???
>
> *Is there any bug in TLAB (core-libs) ?
> Should I send such issue to hotspot team ?
> *
>
> *Test using ThreadLocal AAShapePipeContext:*
> {
>     AAShapePipeContext ctx = getThreadContext();
>     int abox[] = ctx.abox;
>
>     // use array:
>     // mimic: AATileGenerator aatg = renderengine.getAATileGenerator(x, y,
> dx1, dy1, dx2, dy2, 0, 0, clip, abox);
>     abox[0] = 7;
>     abox[1] = 11;
>     abox[2] = 13;
>     abox[3] = 17;
>
>     // mimic: renderTiles(sg, computeBBox(ux1, uy1, ux2, uy2), aatg, abox);
>     devNull1.yield(abox);
>
>     if (!useThreadLocal) {
>         restoreContext(ctx);
>     }
> }
>
> -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728
> -XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal
> -XX:+UseCompressedKlassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
> >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24]
> #-------------------------------------------------------------
> # ContextGetInt4: run duration: 10 000 ms
> #
> # Warm up:
> #           4 threads, Tavg =     13,84 ns/op (? =   0,23 ns/op), Total
> ops =   2889056179 [    13,93 (717199825),     13,87 (720665624),     13,48
> (741390545),     14,09 (709800185)]
> #           4 threads, Tavg =     14,25 ns/op (? =   0,57 ns/op), Total
> ops =   2811615084 [    15,21 (658351236),     14,18 (706254551),     13,94
> (718202949),     13,74 (728806348)]
> cleanup (explicit Full GC) ...
> cleanup done.
> # Measure:
> *1 threads, Tavg =      5,96 ns/op (? =   0,00 ns/op), Total ops =
> 1678357614 [     5,96 (1678357614)]
> 2 threads, Tavg =      7,33 ns/op (? =   0,03 ns/op), Total ops =
> 2729723450 [     7,31 (1369694121),      7,36 (1360029329)]
> 3 threads, Tavg =     10,65 ns/op (? =   2,73 ns/op), Total ops =
> 2817154340 [    13,24 (755190111),     13,23 (755920429),      7,66
> (1306043800)]
> **4 threads, Tavg =     15,44 ns/op (? =   3,33 ns/op), Total ops =
> 2589897733 [    17,05 (586353618),     19,23 (519345153),     17,88
> (559401974),     10,81 *(924796988)]
> #
> << JVM END
>
> *Test using standard int[4] allocation:*
> {
>     int abox[] = new int[4];
>
>       // use array:
>     // mimic: AATileGenerator aatg = renderengine.getAATileGenerator(x, y,
> dx1, dy1, dx2, dy2, 0, 0, clip, abox);
>     abox[0] = 7;
>     abox[1] = 11;
>     abox[2] = 13;
>     abox[3] = 17;
>
>     // mimic: renderTiles(sg, computeBBox(ux1, uy1, ux2, uy2), aatg, abox);
>     devNull1.yield(abox);
> }
>
> -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728
> -XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal
> -XX:+UseCompressedKlassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
> >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24]
> #-------------------------------------------------------------
> # GetInt4: run duration: 10 000 ms
> #
> # Warm up:
> #           4 threads, Tavg =     31,07 ns/op (? =   0,60 ns/op), Total
> ops =   1287292142 [    30,26 (330475567),     31,92 (313328449),     31,27
> (319805520),     30,89 (323682606)]
> #           4 threads, Tavg =     30,94 ns/op (? =   0,33 ns/op), Total
> ops =   1293000783 [    30,92 (323382193),     30,61 (326730340),     31,48
> (317621402),     30,74 (325266848)]
> cleanup (explicit Full GC) ...
> cleanup done.
> # Measure:
> *1 threads, Tavg =      8,27 ns/op (? =   0,00 ns/op), Total ops =
> 1209213909 [     8,27 (1209213909)]
> 2 threads, Tavg =     14,96 ns/op (? =   0,04 ns/op), Total ops =
> 1337024734 [    15,00 (666659967),     14,92 (670364767)]
> 3 threads, Tavg =     20,40 ns/op (? =   1,03 ns/op), Total ops =
> 1470560922 [    21,21 (471592958),     19,00 (526302911),     21,16
> (472665053)]
> **4 threads, Tavg =     29,83 ns/op (? =   1,82 ns/op), Total ops =
> 1340065128 [    31,17 (320806983),     31,58 (316358130),     26,94
> (370806790),     30,11 *(332093225)]
> #
> << JVM END
>
> Best regards,
> Laurent
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Wed Apr 10 19:19:21 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 10 Apr 2013 19:19:21 -0000
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: 
References: 
	<51644C6F.1070404@oracle.com>
	
	<5164538B.9080804@oracle.com>
	
Message-ID: <524F14A3.6080909@oracle.com>

Hi, Laurent.
I am not an expert here but just my 50 cents.
This optimization shall take place only if it is really hotspot. But if 
it is a really hotspot - probably it would be better to remove these 
array/object allocation at all and use plane bytes?
I see that some methods which take it as argument doesn't use them. And 
most of the time we pass AATileGenerator and abox[] to the same methods, 
so it could be merged?

Also I suggest to use jmh for java micrbenchmarks.
http://openjdk.java.net/projects/code-tools/jmh
So your test will be:
http://cr.openjdk.java.net/~serb/AAShapePipeBenchmark.java



-- 
Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Wed Apr 10 19:21:23 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 10 Apr 2013 19:21:23 -0000
Subject: [OpenJDK 2D-Dev]  [8] Request for review: 8000629
 [macosx] Blurry rendering with Java 7 on Retina display
In-Reply-To: <515F13AC.50907@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com> <515F13AC.50907@oracle.com>
Message-ID: <524F151E.6020500@oracle.com>

Hi, Jim, Phil.
Once again=) I assume, that you haven't additional comments? Can I 
consider you as the reviewers?
Note that I plan push it to awt-dev because, my other fixes depend on it.

On 4/5/13 10:10 PM, Sergey Bylokhov wrote:
> Hi, Phil.
> Could you please send me a screenshot and steps to reproduce.
> Note that you should change hidpi mode before start j2ddemo.
>
> On 4/5/13 10:00 PM, Phil Race wrote:
>> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
>> last week.
>> That needs to be fixed before you push.
>>
>> -phil.
>>
>> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>>> Hi, Jim.
>>> I assume, that you haven't additional comments? Can I consider you 
>>> as the second reviewer?
>>> Note that I plan push it to awt-dev because, my other fixes depend 
>>> on it.
>>>
>>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>>> Hello,
>>>> Please review the fix for jdk 8.
>>>> Change adds initial support of hidpi(mostly on 2d side). In the fix 
>>>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This 
>>>> scale factor maps virtual coordinates to physical pixels.
>>>> This change doesn't add support of hidpi to aqua l&f and doesn't 
>>>> add support of dynamic change of scale factor.
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>>> -- 
>>>> Best regards, Sergey.
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>
>


-- 
Best regards, Sergey.



From philip.race at oracle.com  Wed Apr 10 19:47:24 2013
From: philip.race at oracle.com (Phil Race)
Date: Wed, 10 Apr 2013 12:47:24 -0700
Subject: [OpenJDK 2D-Dev]  [8] Request for review: 8000629
 [macosx] Blurry rendering with Java 7 on Retina display
In-Reply-To: <524F151E.6020500@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com> <515F13AC.50907@oracle.com>
	<524F151E.6020500@oracle.com>
Message-ID: <5165C1CC.50608@oracle.com>

I skimmed the updated version but I haven't had a chance to try it out yet.
I'll try to do so later today or tomorrow.

-phil.

On 10/4/2013 12:21 PM, Sergey Bylokhov wrote:
> Hi, Jim, Phil.
> Once again=) I assume, that you haven't additional comments? Can I 
> consider you as the reviewers?
> Note that I plan push it to awt-dev because, my other fixes depend on it.
>
> On 4/5/13 10:10 PM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> Could you please send me a screenshot and steps to reproduce.
>> Note that you should change hidpi mode before start j2ddemo.
>>
>> On 4/5/13 10:00 PM, Phil Race wrote:
>>> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
>>> last week.
>>> That needs to be fixed before you push.
>>>
>>> -phil.
>>>
>>> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>>>> Hi, Jim.
>>>> I assume, that you haven't additional comments? Can I consider you 
>>>> as the second reviewer?
>>>> Note that I plan push it to awt-dev because, my other fixes depend 
>>>> on it.
>>>>
>>>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk 8.
>>>>> Change adds initial support of hidpi(mostly on 2d side). In the 
>>>>> fix scale was added to the surface data/CGraphicsDevice /CGLLayer. 
>>>>> This scale factor maps virtual coordinates to physical pixels.
>>>>> This change doesn't add support of hidpi to aqua l&f and doesn't 
>>>>> add support of dynamic change of scale factor.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>
>>
>>
>
>



From bourges.laurent at gmail.com  Wed Apr 10 19:46:33 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Wed, 10 Apr 2013 21:46:33 +0200
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: <524F14A3.6080909@oracle.com>
References: 
	<51644C6F.1070404@oracle.com>
	
	<5164538B.9080804@oracle.com>
	
	<524F14A3.6080909@oracle.com>
Message-ID: 

Sergey,

I am not an expert here but just my 50 cents.
> This optimization shall take place only if it is really hotspot. But if it
> is a really hotspot - probably it would be better to remove these
> array/object allocation at all and use plane bytes?
>

Java2D calls AAShapePipe for each shape (line, rectangle ...) rendering so
it is an hotspot for me for big drawings as it will depends on the drawing
complexity (for example, Andrea MapBench can produce maps having more than
100 000 shapes per image ...)


> I see that some methods which take it as argument doesn't use them. And
> most of the time we pass AATileGenerator and abox[] to the same methods, so
> it could be merged?
>

For now I did not want to modify the AAShapePipe signatures: abox[] is
filled by AATileGenerator implementations (ductus, pisces, others) in order
to have the shape bounds and render only tiles covering this area.


>
> Also I suggest to use jmh for java micrbenchmarks.
> http://openjdk.java.net/**projects/code-tools/jmh
> So your test will be:
> http://cr.openjdk.java.net/~**serb/AAShapePipeBenchmark.java
>

Thanks,
I will try it asap

Laurent

>
>
>
> --
> Best regards, Sergey.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From peter.levart at gmail.com  Wed Apr 10 10:17:58 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 10 Apr 2013 12:17:58 +0200
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: 
References: 
	<51644C6F.1070404@oracle.com>
	
	<5164538B.9080804@oracle.com>
	
Message-ID: <51653C56.1010306@gmail.com>

Hi Laurent,

Could you disable tiered compilation for performance tests? Tiered 
compilation is usually a source of jitter in the results. Pass 
-XX:-TieredCompilation to the VM.

Regards, Peter


On 04/10/2013 10:58 AM, Laurent Bourg?s wrote:

> Dear Jim,
>
> 2013/4/9 Jim Graham  >
>
>
>     The allocations will always show up on a heap profiler, I don't
>     know of any way of having them not show up if they are stack
>     allocated, but I don't think that stack allocation is the issue
>     here - small allocations come out of a fast generation that costs
>     almost nothing to allocate from and nearly nothing to clean up.
>      They are actually getting allocated and GC'd, but the process is
>     optimized.
>
>     The only way to tell is to benchmark and see which changes make a
>     difference and which are in the noise (or, in some odd
>     counter-intuitive cases, counter-productive)...
>
>                             ...jim
>
>
> I advocate I like GC because it avoids in Java dealing with pointers 
> like C/C++ does; however, I prefer GC clean real garbage 
> (application...) than wasted memory:
> I prefer not count on GC when I can avoid wasting memory that gives GC 
> more work = reduce useless garbage (save the planet) !
>
> Moreover, GC and / or Thread local allocation (TLAB) seems to have 
> more overhead than you think = "fast generation that costs almost 
> nothing to allocate from and nearly nothing to clean up".
>
> Here are my micro-benchmark results related to int[4] allocation where 
> I mimic the AAShapePipe.fillParallelogram() method:
> Patch 	Ref 	Gain
> 5,96 	8,27 	138,76%
> 7,31 	14,96 	204,65%
> 10,65 	20,4 	191,55%
> 15,44 	29,83 	193,20%
>
>
> Test environment:
> Linux64 with OpenJDK8 (2 real cpu cores, 4 virtual cpus)
> JVM settings:
> -XX:+PrintCommandLineFlags -XX:-PrintFlagsFinal -Xms128m  -Xmx128m
>
> Benchmark code (using Peter Levart microbench classes):
> http://jmmc.fr/~bourgesl/share/AAShapePipe/microbench/ 
> 
>
> My conclusion is:  "nothing" > zero (allocation + cleanup) and it is 
> very noticeable in multi threading tests.
>
> I advocate that I use a dirty int[4] array (no cleanup) but it is not 
> necessary : maybe the performance gain come from that reason.
>
>
> Finally here is the output with  -XX:+PrintTLAB flag:
> TLAB: gc thread: 0x00007f105813d000 [id: 4053] desired_size: 1312KB 
> slow allocs: 0  refill waste: 20992B alloc: 1,00000 65600KB refills: 
> 20 waste  1,2% gc: 323712B slow: 600B fast: 0B
> TLAB: gc thread: 0x00007f105813a800 [id: 4052] desired_size: 1312KB 
> slow allocs: 0  refill waste: 20992B alloc: 1,00000 65600KB refills: 7 
> waste  7,9% gc: 745568B slow: 176B fast: 0B
> TLAB: gc thread: 0x00007f1058138800 [id: 4051] desired_size: 1312KB 
> slow allocs: 0  refill waste: 20992B alloc: 1,00000 65600KB refills: 
> 15 waste  3,1% gc: 618464B slow: 448B fast: 0B
> TLAB: gc thread: 0x00007f1058136800 [id: 4050] desired_size: 1312KB 
> slow allocs: 0  refill waste: 20992B alloc: 1,00000 65600KB refills: 7 
> waste  0,0% gc: 0B slow: 232B fast: 0B
> TLAB: gc thread: 0x00007f1058009000 [id: 4037] desired_size: 1312KB 
> slow allocs: 0  refill waste: 20992B alloc: 1,00000 65600KB refills: 1 
> waste 27,5% gc: 369088B slow: 0B fast: 0B
> TLAB totals: thrds: 5  refills: 50 max: 20 slow allocs: 0 max 0 
> waste:  3,1% gc: 2056832B max: 745568B slow: 1456B max: 600B fast: 0B 
> max: 0B
>
> I would have expected that TLAB can recycle all useless int[4] arrays 
> as fast as possible => waste = 100% ???
>
> *Is there any bug in TLAB (core-libs) ?
> Should I send such issue to hotspot team ?
> *
>
> *Test using ThreadLocal AAShapePipeContext:*
> {
> AAShapePipeContext ctx = getThreadContext();
> int abox[] = ctx.abox;
>
>     // use array:
>     // mimic: AATileGenerator aatg = 
> renderengine.getAATileGenerator(x, y, dx1, dy1, dx2, dy2, 0, 0, clip, 
> abox);
>     abox[0] = 7;
>     abox[1] = 11;
>     abox[2] = 13;
>     abox[3] = 17;
>
>     // mimic: renderTiles(sg, computeBBox(ux1, uy1, ux2, uy2), aatg, 
> abox);
> devNull1.yield(abox);
>
>     if (!useThreadLocal) {
> restoreContext(ctx);
>     }
> }
>
> -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728 
> -XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags 
> -XX:-PrintFlagsFinal -XX:+UseCompressedKlassPointers 
> -XX:+UseCompressedOops -XX:+UseParallelGC
> >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24]
> #-------------------------------------------------------------
> # ContextGetInt4: run duration: 10 000 ms
> #
> # Warm up:
> #           4 threads, Tavg =     13,84 ns/op (? =   0,23 ns/op), 
> Total ops =   2889056179 [    13,93 (717199825),     13,87 
> (720665624),     13,48 (741390545),     14,09 (709800185)]
> #           4 threads, Tavg =     14,25 ns/op (? =   0,57 ns/op), 
> Total ops =   2811615084 [    15,21 (658351236),     14,18 
> (706254551),     13,94 (718202949),     13,74 (728806348)]
> cleanup (explicit Full GC) ...
> cleanup done.
> # Measure:
> *1 threads, Tavg =      5,96 ns/op (? =   0,00 ns/op), Total ops =   
> 1678357614 [     5,96 (1678357614)]
> 2 threads, Tavg =      7,33 ns/op (? =   0,03 ns/op), Total ops =   
> 2729723450 [     7,31 (1369694121),      7,36 (1360029329)]
> 3 threads, Tavg =     10,65 ns/op (? =   2,73 ns/op), Total ops =   
> 2817154340 [    13,24 (755190111),     13,23 (755920429),      7,66 
> (1306043800)]
> **4 threads, Tavg =     15,44 ns/op (? =   3,33 ns/op), Total ops = 
> 2589897733 [    17,05 (586353618),     19,23 (519345153), 17,88 
> (559401974),     10,81 *(924796988)]
> #
> << JVM END
>
> *Test using standard int[4] allocation:*
> {
> int abox[] = new int[4];
>
> // use array:
>     // mimic: AATileGenerator aatg = 
> renderengine.getAATileGenerator(x, y, dx1, dy1, dx2, dy2, 0, 0, clip, 
> abox);
>     abox[0] = 7;
>     abox[1] = 11;
>     abox[2] = 13;
>     abox[3] = 17;
>
>     // mimic: renderTiles(sg, computeBBox(ux1, uy1, ux2, uy2), aatg, 
> abox);
> devNull1.yield(abox);
> }
>
> -XX:ClassMetaspaceSize=104857600 -XX:InitialHeapSize=134217728 
> -XX:MaxHeapSize=134217728 -XX:+PrintCommandLineFlags 
> -XX:-PrintFlagsFinal -XX:+UseCompressedKlassPointers 
> -XX:+UseCompressedOops -XX:+UseParallelGC
> >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b24]
> #-------------------------------------------------------------
> # GetInt4: run duration: 10 000 ms
> #
> # Warm up:
> #           4 threads, Tavg =     31,07 ns/op (? =   0,60 ns/op), 
> Total ops =   1287292142 [    30,26 (330475567),     31,92 
> (313328449),     31,27 (319805520),     30,89 (323682606)]
> #           4 threads, Tavg =     30,94 ns/op (? =   0,33 ns/op), 
> Total ops =   1293000783 [    30,92 (323382193),     30,61 
> (326730340),     31,48 (317621402),     30,74 (325266848)]
> cleanup (explicit Full GC) ...
> cleanup done.
> # Measure:
> *1 threads, Tavg =      8,27 ns/op (? =   0,00 ns/op), Total ops =   
> 1209213909 [     8,27 (1209213909)]
> 2 threads, Tavg =     14,96 ns/op (? =   0,04 ns/op), Total ops =   
> 1337024734 [    15,00 (666659967),     14,92 (670364767)]
> 3 threads, Tavg =     20,40 ns/op (? =   1,03 ns/op), Total ops =   
> 1470560922 [    21,21 (471592958),     19,00 (526302911),     21,16 
> (472665053)]
> **4 threads, Tavg =     29,83 ns/op (? =   1,82 ns/op), Total ops = 
> 1340065128 [    31,17 (320806983),     31,58 (316358130), 26,94 
> (370806790),     30,11 *(332093225)]
> #
> << JVM END
>
> Best regards,
> Laurent
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From james.graham at oracle.com  Wed Apr 10 21:37:12 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 10 Apr 2013 14:37:12 -0700
Subject: [OpenJDK 2D-Dev]  [8] Request for review: 8000629
 [macosx] Blurry rendering with Java 7 on Retina display
In-Reply-To: <524F151E.6020500@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com> <515F13AC.50907@oracle.com>
	<524F151E.6020500@oracle.com>
Message-ID: <5165DB88.2090600@oracle.com>

I took one last glance through the .06 webrev.  I don't see any more 
issues...

		...jim

On 10/4/13 12:21 PM, Sergey Bylokhov wrote:
> Hi, Jim, Phil.
> Once again=) I assume, that you haven't additional comments? Can I
> consider you as the reviewers?
> Note that I plan push it to awt-dev because, my other fixes depend on it.
>
> On 4/5/13 10:10 PM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> Could you please send me a screenshot and steps to reproduce.
>> Note that you should change hidpi mode before start j2ddemo.
>>
>> On 4/5/13 10:00 PM, Phil Race wrote:
>>> SFAIK you haven't fixed the problem with TexturePaint I pointed out
>>> last week.
>>> That needs to be fixed before you push.
>>>
>>> -phil.
>>>
>>> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>>>> Hi, Jim.
>>>> I assume, that you haven't additional comments? Can I consider you
>>>> as the second reviewer?
>>>> Note that I plan push it to awt-dev because, my other fixes depend
>>>> on it.
>>>>
>>>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk 8.
>>>>> Change adds initial support of hidpi(mostly on 2d side). In the fix
>>>>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This
>>>>> scale factor maps virtual coordinates to physical pixels.
>>>>> This change doesn't add support of hidpi to aqua l&f and doesn't
>>>>> add support of dynamic change of scale factor.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>>>> Webrev can be found at:
>>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>>>> --
>>>>> Best regards, Sergey.
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>
>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed Apr 10 22:59:53 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 11 Apr 2013 02:59:53 +0400
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: 
References: 
	<51644C6F.1070404@oracle.com>
	
	<5164538B.9080804@oracle.com>
	
	<524F14A3.6080909@oracle.com>
	
Message-ID: <5165EEE9.1050006@oracle.com>

On 4/10/13 11:46 PM, Laurent Bourg?s wrote:
>> I see that some methods which take it as argument doesn't use them. And
>> most of the time we pass AATileGenerator and abox[] to the same methods, so
>> it could be merged?
>>
> For now I did not want to modify the AAShapePipe signatures: abox[] is
> filled by AATileGenerator implementations (ductus, pisces, others) in order
> to have the shape bounds and render only tiles covering this area.
You still have to check all the places, where these objects are filled 
and used, and refactoring is a good start, no?
Otherwise, how can you prove that these arrays are used as you would 
expect, These arrays could be stored like the cache or re-used for other 
purpose(if someone don't want to create new arrays).
Probably it will be good to split all your changes / to a few CR.
  - cleanup
  - Some small changes which gave us most speedup
  - all other things.
??
>
>> Also I suggest to use jmh for java micrbenchmarks.
>> http://openjdk.java.net/**projects/code-tools/jmh
>> So your test will be:
>> http://cr.openjdk.java.net/~**serb/AAShapePipeBenchmark.java
>>
> Thanks,
> I will try it asap
>
> Laurent
>
>>
>> --
>> Best regards, Sergey.
>>
>>


-- 
Best regards, Sergey.



From james.graham at oracle.com  Thu Apr 11 00:06:24 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 10 Apr 2013 17:06:24 -0700
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: <5165EEE9.1050006@oracle.com>
References: 
	<51644C6F.1070404@oracle.com>
	
	<5164538B.9080804@oracle.com>
	
	<524F14A3.6080909@oracle.com>
	
	<5165EEE9.1050006@oracle.com>
Message-ID: <5165FE80.9040408@oracle.com>

I'm pretty familiar with all of this code and there aren't any places 
that save the tile array that I remember.  The embedded code that Pisces 
was taken from had some caching of alpha arrays, but we didn't use or 
keep that when we converted it for use in the JDK...

It occurs to me that since you are collecting the various pieces of 
information into an object to store in the thread local storage, perhaps 
we should convert to a paradigm where an entire Tile Generation sequence 
uses that object "TileState?" as its main way to communicate info around 
the various stages.  Thus, you don't really need an int[4] to store the 
4 parameters, they could be stored directly in the TileState object. 
This would require more sweeping changes to the pipeline, but it might 
make the code a bit more readable (and make the hits to convert over 
more moot as they would be improving readability and give more focus to 
the relationships between all of the various bits of data).  Then it 
simply becomes a matter of managing the lifetime and allocation of the 
TileState objects which is a minor update to the newly refactored code.

			...jim

On 4/10/13 3:59 PM, Sergey Bylokhov wrote:
> On 4/10/13 11:46 PM, Laurent Bourg?s wrote:
>>> I see that some methods which take it as argument doesn't use them. And
>>> most of the time we pass AATileGenerator and abox[] to the same
>>> methods, so
>>> it could be merged?
>>>
>> For now I did not want to modify the AAShapePipe signatures: abox[] is
>> filled by AATileGenerator implementations (ductus, pisces, others) in
>> order
>> to have the shape bounds and render only tiles covering this area.
> You still have to check all the places, where these objects are filled
> and used, and refactoring is a good start, no?
> Otherwise, how can you prove that these arrays are used as you would
> expect, These arrays could be stored like the cache or re-used for other
> purpose(if someone don't want to create new arrays).
> Probably it will be good to split all your changes / to a few CR.
>   - cleanup
>   - Some small changes which gave us most speedup
>   - all other things.
> ??
>>
>>> Also I suggest to use jmh for java micrbenchmarks.
>>> http://openjdk.java.net/**projects/code-tools/jmh
>>>
>>> So your test will be:
>>> http://cr.openjdk.java.net/~**serb/AAShapePipeBenchmark.java
>>>
>>>
>> Thanks,
>> I will try it asap
>>
>> Laurent
>>
>>>
>>> --
>>> Best regards, Sergey.
>>>
>>>
>
>


From bourges.laurent at gmail.com  Thu Apr 11 13:07:59 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 11 Apr 2013 15:07:59 +0200
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: <5165FE80.9040408@oracle.com>
References: 
	<51644C6F.1070404@oracle.com>
	
	<5164538B.9080804@oracle.com>
	
	<524F14A3.6080909@oracle.com>
	
	<5165EEE9.1050006@oracle.com> <5165FE80.9040408@oracle.com>
Message-ID: 

Jim and Sergey,

1/ Here are few benchmarks (based on mapBench again) running several
modified versions of AAShapePipe:
http://jmmc.fr/~bourgesl/share/AAShapePipe/mapBench/
- ref:
1 threads and 20 loops per thread, time: 3742 ms
2 threads and 20 loops per thread, time: 4756 ms
4 threads and 20 loops per thread, time: 8528 ms

1 threads and 20 loops per thread, time: 56264 ms
2 threads and 20 loops per thread, time: 75566 ms
4 threads and 20 loops per thread, time: 141546 ms

- int4:
1 threads and 20 loops per thread, time: 3653 ms
2 threads and 20 loops per thread, time: 4684 ms
4 threads and 20 loops per thread, time: 8291 ms

1 threads and 20 loops per thread, time: 55950 ms
2 threads and 20 loops per thread, time: 74796 ms
4 threads and 20 loops per thread, time: 139924 ms

- byte[]:
1 threads and 20 loops per thread, time: 3795 ms
2 threads and 20 loops per thread, time: 4605 ms
4 threads and 20 loops per thread, time: 8246 ms

1 threads and 20 loops per thread, time: 54961 ms
2 threads and 20 loops per thread, time: 72768 ms
4 threads and 20 loops per thread, time: 139430 ms

- int4 / byte[] / rectangle cached in TileState:
1 threads and 20 loops per thread, time: 3610 ms
2 threads and 20 loops per thread, time: 4481 ms
4 threads and 20 loops per thread, time: 8225 ms

1 threads and 20 loops per thread, time: 54651 ms
2 threads and 20 loops per thread, time: 74516 ms
4 threads and 20 loops per thread, time: 140153 ms

So you may be right, results are varying depending on the optimizations
(int4, byte or all) !
Maybe I should test different versions on optimized pisces renderer ...

Here is an updated patch:
http://jmmc.fr/~bourgesl/share/AAShapePipe/webrev-2/


2/ Thanks for your comments: actually a refactoring is possible to use a
(shared) TileState instance replacing int[] bbox, rectangle bbox):
- RenderingEngine.AATileGenerator getAATileGenerator(... int[] abox)

it is very interesting here to propose an extensible tile state: maybe
created by the renderer engine to cache other data ?

- Rectangle and Rectangle2D are only used as the shape s and device
rectangle given to CompositePipe.startSequence():
    public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev,
int[] abox);

Changing this interface may become difficult:
AlphaColorPipe.java:
    41:  public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev,
OK, [s, dev, abox] unused

AlphaPaintPipe.java
    81:  public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR,
create a paint context:
        PaintContext paintContext =
            sg.paint.createContext(sg.getDeviceColorModel(),
                                   devR,
                                   s.getBounds2D(),
                                   sg.cloneTransform(),
                                   sg.getRenderingHints());

GeneralCompositePipe.java:
    62:  public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR,
abox unused and create a paint context:
        PaintContext paintContext =
            sg.paint.createContext(model, devR, s.getBounds2D(),
                                   sg.cloneTransform(),
                                   hints);

SpanClipRenderer.java
    68:  public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR,
Forward to another composite pipe
return new SCRcontext(ri, outpipe.startSequence(sg, s, devR, abox));

It could be possible to use TileState into PaintContext interface / fix
implementations but it may become a tricky change (API change).

What do you think ?

Laurent

2013/4/11 Jim Graham 

> I'm pretty familiar with all of this code and there aren't any places that
> save the tile array that I remember.  The embedded code that Pisces was
> taken from had some caching of alpha arrays, but we didn't use or keep that
> when we converted it for use in the JDK...
>
> It occurs to me that since you are collecting the various pieces of
> information into an object to store in the thread local storage, perhaps we
> should convert to a paradigm where an entire Tile Generation sequence uses
> that object "TileState?" as its main way to communicate info around the
> various stages.  Thus, you don't really need an int[4] to store the 4
> parameters, they could be stored directly in the TileState object. This
> would require more sweeping changes to the pipeline, but it might make the
> code a bit more readable (and make the hits to convert over more moot as
> they would be improving readability and give more focus to the
> relationships between all of the various bits of data).  Then it simply
> becomes a matter of managing the lifetime and allocation of the TileState
> objects which is a minor update to the newly refactored code.
>
>                         ...jim
>
> On 4/10/13 3:59 PM, Sergey Bylokhov wrote:
>
>  On 4/10/13 11:46 PM, Laurent Bourg?s wrote:
>>
>>> I see that some methods which take it as argument doesn't use them. And
>>>> most of the time we pass AATileGenerator and abox[] to the same
>>>> methods, so
>>>> it could be merged?
>>>>
>>>>  For now I did not want to modify the AAShapePipe signatures: abox[] is
>>> filled by AATileGenerator implementations (ductus, pisces, others) in
>>> order
>>> to have the shape bounds and render only tiles covering this area.
>>>
>> You still have to check all the places, where these objects are filled
>> and used, and refactoring is a good start, no?
>> Otherwise, how can you prove that these arrays are used as you would
>> expect, These arrays could be stored like the cache or re-used for other
>> purpose(if someone don't want to create new arrays).
>> Probably it will be good to split all your changes / to a few CR.
>>   - cleanup
>>   - Some small changes which gave us most speedup
>>   - all other things.
>> ??
>>
>>>
>>>  Also I suggest to use jmh for java micrbenchmarks.
>>>> http://openjdk.java.net/****projects/code-tools/jmh
>>>> 
>>>> >
>>>>
>>>> So your test will be:
>>>> http://cr.openjdk.java.net/~****serb/AAShapePipeBenchmark.java
>>>> **
>>>> >
>>>>
>>>>
>>>>  Thanks,
>>> I will try it asap
>>>
>>> Laurent
>>>
>>>
>>>> --
>>>> Best regards, Sergey.
>>>>
>>>>
>>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bourges.laurent at gmail.com  Thu Apr 11 13:29:56 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 11 Apr 2013 15:29:56 +0200
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: 
References: 
	<51644C6F.1070404@oracle.com>
	
	<5164538B.9080804@oracle.com>
	
	<524F14A3.6080909@oracle.com>
	
	<5165EEE9.1050006@oracle.com> <5165FE80.9040408@oracle.com>
	
Message-ID: 

Last idea: I will enhance Andrea's mapBench benchmark to have statistics
per threads: number of loops, avg, min, max, stddev;

I guess that the total bench time is not so representative as the thread
pool can distribute the work load differently at each test => statistics
will help to have better timing / comparison between bench runs.

Regards,
Laurent

2013/4/11 Laurent Bourg?s 

> Jim and Sergey,
>
> 1/ Here are few benchmarks (based on mapBench again) running several
> modified versions of AAShapePipe:
> http://jmmc.fr/~bourgesl/share/AAShapePipe/mapBench/
> - ref:
> 1 threads and 20 loops per thread, time: 3742 ms
> 2 threads and 20 loops per thread, time: 4756 ms
> 4 threads and 20 loops per thread, time: 8528 ms
>
> 1 threads and 20 loops per thread, time: 56264 ms
> 2 threads and 20 loops per thread, time: 75566 ms
> 4 threads and 20 loops per thread, time: 141546 ms
>
> - int4:
> 1 threads and 20 loops per thread, time: 3653 ms
> 2 threads and 20 loops per thread, time: 4684 ms
> 4 threads and 20 loops per thread, time: 8291 ms
>
> 1 threads and 20 loops per thread, time: 55950 ms
> 2 threads and 20 loops per thread, time: 74796 ms
> 4 threads and 20 loops per thread, time: 139924 ms
>
> - byte[]:
> 1 threads and 20 loops per thread, time: 3795 ms
> 2 threads and 20 loops per thread, time: 4605 ms
> 4 threads and 20 loops per thread, time: 8246 ms
>
> 1 threads and 20 loops per thread, time: 54961 ms
> 2 threads and 20 loops per thread, time: 72768 ms
> 4 threads and 20 loops per thread, time: 139430 ms
>
> - int4 / byte[] / rectangle cached in TileState:
> 1 threads and 20 loops per thread, time: 3610 ms
> 2 threads and 20 loops per thread, time: 4481 ms
> 4 threads and 20 loops per thread, time: 8225 ms
>
> 1 threads and 20 loops per thread, time: 54651 ms
> 2 threads and 20 loops per thread, time: 74516 ms
> 4 threads and 20 loops per thread, time: 140153 ms
>
> So you may be right, results are varying depending on the optimizations
> (int4, byte or all) !
> Maybe I should test different versions on optimized pisces renderer ...
>
> Here is an updated patch:
> http://jmmc.fr/~bourgesl/share/AAShapePipe/webrev-2/
>
>
> 2/ Thanks for your comments: actually a refactoring is possible to use a
> (shared) TileState instance replacing int[] bbox, rectangle bbox):
> - RenderingEngine.AATileGenerator getAATileGenerator(... int[] abox)
>
> it is very interesting here to propose an extensible tile state: maybe
> created by the renderer engine to cache other data ?
>
> - Rectangle and Rectangle2D are only used as the shape s and device
> rectangle given to CompositePipe.startSequence():
>     public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev,
> int[] abox);
>
> Changing this interface may become difficult:
> AlphaColorPipe.java:
>
>     41:  public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev,
> OK, [s, dev, abox] unused
>
> AlphaPaintPipe.java
>
>     81:  public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR,
> create a paint context:
>         PaintContext paintContext =
>             sg.paint.createContext(sg.getDeviceColorModel(),
>                                    devR,
>                                    s.getBounds2D(),
>                                    sg.cloneTransform(),
>                                    sg.getRenderingHints());
>
> GeneralCompositePipe.java:
>
>     62:  public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR,
> abox unused and create a paint context:
>         PaintContext paintContext =
>             sg.paint.createContext(model, devR, s.getBounds2D(),
>                                    sg.cloneTransform(),
>                                    hints);
>
> SpanClipRenderer.java
>
>     68:  public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR,
> Forward to another composite pipe
> return new SCRcontext(ri, outpipe.startSequence(sg, s, devR, abox));
>
> It could be possible to use TileState into PaintContext interface / fix
> implementations but it may become a tricky change (API change).
>
> What do you think ?
>
> Laurent
>
>
> 2013/4/11 Jim Graham 
>
>> I'm pretty familiar with all of this code and there aren't any places
>> that save the tile array that I remember.  The embedded code that Pisces
>> was taken from had some caching of alpha arrays, but we didn't use or keep
>> that when we converted it for use in the JDK...
>>
>> It occurs to me that since you are collecting the various pieces of
>> information into an object to store in the thread local storage, perhaps we
>> should convert to a paradigm where an entire Tile Generation sequence uses
>> that object "TileState?" as its main way to communicate info around the
>> various stages.  Thus, you don't really need an int[4] to store the 4
>> parameters, they could be stored directly in the TileState object. This
>> would require more sweeping changes to the pipeline, but it might make the
>> code a bit more readable (and make the hits to convert over more moot as
>> they would be improving readability and give more focus to the
>> relationships between all of the various bits of data).  Then it simply
>> becomes a matter of managing the lifetime and allocation of the TileState
>> objects which is a minor update to the newly refactored code.
>>
>>                         ...jim
>>
>> On 4/10/13 3:59 PM, Sergey Bylokhov wrote:
>>
>>  On 4/10/13 11:46 PM, Laurent Bourg?s wrote:
>>>
>>>> I see that some methods which take it as argument doesn't use them. And
>>>>> most of the time we pass AATileGenerator and abox[] to the same
>>>>> methods, so
>>>>> it could be merged?
>>>>>
>>>>>  For now I did not want to modify the AAShapePipe signatures: abox[] is
>>>> filled by AATileGenerator implementations (ductus, pisces, others) in
>>>> order
>>>> to have the shape bounds and render only tiles covering this area.
>>>>
>>> You still have to check all the places, where these objects are filled
>>> and used, and refactoring is a good start, no?
>>> Otherwise, how can you prove that these arrays are used as you would
>>> expect, These arrays could be stored like the cache or re-used for other
>>> purpose(if someone don't want to create new arrays).
>>> Probably it will be good to split all your changes / to a few CR.
>>>   - cleanup
>>>   - Some small changes which gave us most speedup
>>>   - all other things.
>>> ??
>>>
>>>>
>>>>  Also I suggest to use jmh for java micrbenchmarks.
>>>>> http://openjdk.java.net/****projects/code-tools/jmh
>>>>> 
>>>>> >
>>>>>
>>>>> So your test will be:
>>>>> http://cr.openjdk.java.net/~****serb/AAShapePipeBenchmark.java
>>>>> **
>>>>> >
>>>>>
>>>>>
>>>>>  Thanks,
>>>> I will try it asap
>>>>
>>>> Laurent
>>>>
>>>>
>>>>> --
>>>>> Best regards, Sergey.
>>>>>
>>>>>
>>>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From philip.race at oracle.com  Thu Apr 11 19:33:21 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 11 Apr 2013 12:33:21 -0700
Subject: [OpenJDK 2D-Dev]  [8] Request for review: 8000629
 [macosx] Blurry rendering with Java 7 on Retina display
In-Reply-To: <524F151E.6020500@oracle.com>
References: <5151BFCA.1060702@oracle.com> <515F01AE.4050409@oracle.com>
	<515F1121.4020107@oracle.com> <515F13AC.50907@oracle.com>
	<524F151E.6020500@oracle.com>
Message-ID: <51671001.5010302@oracle.com>

I am now fine with this latest version.

-phil.

On 10/4/13 12:21 PM, Sergey Bylokhov wrote:
> Hi, Jim, Phil.
> Once again=) I assume, that you haven't additional comments? Can I 
> consider you as the reviewers?
> Note that I plan push it to awt-dev because, my other fixes depend on it.
>
> On 4/5/13 10:10 PM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> Could you please send me a screenshot and steps to reproduce.
>> Note that you should change hidpi mode before start j2ddemo.
>>
>> On 4/5/13 10:00 PM, Phil Race wrote:
>>> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
>>> last week.
>>> That needs to be fixed before you push.
>>>
>>> -phil.
>>>
>>> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>>>> Hi, Jim.
>>>> I assume, that you haven't additional comments? Can I consider you 
>>>> as the second reviewer?
>>>> Note that I plan push it to awt-dev because, my other fixes depend 
>>>> on it.
>>>>
>>>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk 8.
>>>>> Change adds initial support of hidpi(mostly on 2d side). In the 
>>>>> fix scale was added to the surface data/CGraphicsDevice /CGLLayer. 
>>>>> This scale factor maps virtual coordinates to physical pixels.
>>>>> This change doesn't add support of hidpi to aqua l&f and doesn't 
>>>>> add support of dynamic change of scale factor.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>
>>
>>
>
>



From james.graham at oracle.com  Thu Apr 11 21:42:16 2013
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 11 Apr 2013 14:42:16 -0700
Subject: [OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
In-Reply-To: 
References: 
	<51644C6F.1070404@oracle.com>
	
	<5164538B.9080804@oracle.com>
	
	<524F14A3.6080909@oracle.com>
	
	<5165EEE9.1050006@oracle.com> <5165FE80.9040408@oracle.com>
	
Message-ID: <51672E38.10307@oracle.com>

Hi Laurent,

Yes, these kinds of minor optimizations (i.e. optimizations that don't 
make a clear 2x type of savings) can be frustrating at times.  It looks 
like there is potential for a decent return there if we can find the 
right change.  Sometimes rearranging a couple of things that don't look 
like they are saving work can somehow trip the runtime into executing 
the code more efficiently.

I skimmed through your thoughts at the bottom.  It occurred to me after 
I sent that idea out that sometimes we use int[] because we have to hand 
the values to native for return values and there is no easy way to 
return 4 values from a native method.  An array is simplest because it 
can be loaded with answers via a single JNI call.  4 fields in a class 
would require 4xJNI.SetField calls.  It might have better payoff if we 
can cache renderer state there as well which gets into subclassing. 
Also, doing this right may have to be done by someone here at Oracle 
because it may involve modifying the Ductus pipeline to match (it's been 
a while and I don't remember if we open sourced the code that interfaces 
Ductus to the RenderingEngine interfaces...?)

			...jim

On 4/11/13 6:07 AM, Laurent Bourg?s wrote:
> Jim and Sergey,
>
> 1/ Here are few benchmarks (based on mapBench again) running several
> modified versions of AAShapePipe:
> http://jmmc.fr/~bourgesl/share/AAShapePipe/mapBench/
> - ref:
> 1 threads and 20 loops per thread, time: 3742 ms
> 2 threads and 20 loops per thread, time: 4756 ms
> 4 threads and 20 loops per thread, time: 8528 ms
>
> 1 threads and 20 loops per thread, time: 56264 ms
> 2 threads and 20 loops per thread, time: 75566 ms
> 4 threads and 20 loops per thread, time: 141546 ms
>
> - int4:
> 1 threads and 20 loops per thread, time: 3653 ms
> 2 threads and 20 loops per thread, time: 4684 ms
> 4 threads and 20 loops per thread, time: 8291 ms
>
> 1 threads and 20 loops per thread, time: 55950 ms
> 2 threads and 20 loops per thread, time: 74796 ms
> 4 threads and 20 loops per thread, time: 139924 ms
>
> - byte[]:
> 1 threads and 20 loops per thread, time: 3795 ms
> 2 threads and 20 loops per thread, time: 4605 ms
> 4 threads and 20 loops per thread, time: 8246 ms
>
> 1 threads and 20 loops per thread, time: 54961 ms
> 2 threads and 20 loops per thread, time: 72768 ms
> 4 threads and 20 loops per thread, time: 139430 ms
>
> - int4 / byte[] / rectangle cached in TileState:
> 1 threads and 20 loops per thread, time: 3610 ms
> 2 threads and 20 loops per thread, time: 4481 ms
> 4 threads and 20 loops per thread, time: 8225 ms
>
> 1 threads and 20 loops per thread, time: 54651 ms
> 2 threads and 20 loops per thread, time: 74516 ms
> 4 threads and 20 loops per thread, time: 140153 ms
>
> So you may be right, results are varying depending on the optimizations
> (int4, byte or all) !
> Maybe I should test different versions on optimized pisces renderer ...
>
> Here is an updated patch:
> http://jmmc.fr/~bourgesl/share/AAShapePipe/webrev-2/
>
>
> 2/ Thanks for your comments: actually a refactoring is possible to use a
> (shared) TileState instance replacing int[] bbox, rectangle bbox):
> - RenderingEngine.AATileGenerator getAATileGenerator(... int[] abox)
>
> it is very interesting here to propose an extensible tile state: maybe
> created by the renderer engine to cache other data ?
>
> - Rectangle and Rectangle2D are only used as the shape s and device
> rectangle given to CompositePipe.startSequence():
>      public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev,
> int[] abox);
>
> Changing this interface may become difficult:
> AlphaColorPipe.java:
>      41:  public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev,
> OK, [s, dev, abox] unused
>
> AlphaPaintPipe.java
>      81:  public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR,
> create a paint context:
>          PaintContext paintContext =
>              sg.paint.createContext(sg.getDeviceColorModel(),
>                                     devR,
>                                     s.getBounds2D(),
>                                     sg.cloneTransform(),
>                                     sg.getRenderingHints());
>
> GeneralCompositePipe.java:
>      62:  public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR,
> abox unused and create a paint context:
>          PaintContext paintContext =
>              sg.paint.createContext(model, devR, s.getBounds2D(),
>                                     sg.cloneTransform(),
>                                     hints);
>
> SpanClipRenderer.java
>      68:  public Object startSequence(SunGraphics2D sg, Shape s, Rectangle devR,
> Forward to another composite pipe
> return new SCRcontext(ri, outpipe.startSequence(sg, s, devR, abox));
>
> It could be possible to use TileState into PaintContext interface / fix
> implementations but it may become a tricky change (API change).
>
> What do you think ?
>
> Laurent
>
> 2013/4/11 Jim Graham 
>
>> I'm pretty familiar with all of this code and there aren't any places that
>> save the tile array that I remember.  The embedded code that Pisces was
>> taken from had some caching of alpha arrays, but we didn't use or keep that
>> when we converted it for use in the JDK...
>>
>> It occurs to me that since you are collecting the various pieces of
>> information into an object to store in the thread local storage, perhaps we
>> should convert to a paradigm where an entire Tile Generation sequence uses
>> that object "TileState?" as its main way to communicate info around the
>> various stages.  Thus, you don't really need an int[4] to store the 4
>> parameters, they could be stored directly in the TileState object. This
>> would require more sweeping changes to the pipeline, but it might make the
>> code a bit more readable (and make the hits to convert over more moot as
>> they would be improving readability and give more focus to the
>> relationships between all of the various bits of data).  Then it simply
>> becomes a matter of managing the lifetime and allocation of the TileState
>> objects which is a minor update to the newly refactored code.
>>
>>                          ...jim
>>
>> On 4/10/13 3:59 PM, Sergey Bylokhov wrote:
>>
>>   On 4/10/13 11:46 PM, Laurent Bourg?s wrote:
>>>
>>>> I see that some methods which take it as argument doesn't use them. And
>>>>> most of the time we pass AATileGenerator and abox[] to the same
>>>>> methods, so
>>>>> it could be merged?
>>>>>
>>>>>   For now I did not want to modify the AAShapePipe signatures: abox[] is
>>>> filled by AATileGenerator implementations (ductus, pisces, others) in
>>>> order
>>>> to have the shape bounds and render only tiles covering this area.
>>>>
>>> You still have to check all the places, where these objects are filled
>>> and used, and refactoring is a good start, no?
>>> Otherwise, how can you prove that these arrays are used as you would
>>> expect, These arrays could be stored like the cache or re-used for other
>>> purpose(if someone don't want to create new arrays).
>>> Probably it will be good to split all your changes / to a few CR.
>>>    - cleanup
>>>    - Some small changes which gave us most speedup
>>>    - all other things.
>>> ??
>>>
>>>>
>>>>   Also I suggest to use jmh for java micrbenchmarks.
>>>>> http://openjdk.java.net/****projects/code-tools/jmh
>>>>> 
>>>>>>
>>>>>
>>>>> So your test will be:
>>>>> http://cr.openjdk.java.net/~****serb/AAShapePipeBenchmark.java
>>>>> **
>>>>>>
>>>>>
>>>>>
>>>>>   Thanks,
>>>> I will try it asap
>>>>
>>>> Laurent
>>>>
>>>>
>>>>> --
>>>>> Best regards, Sergey.
>>>>>
>>>>>
>>>>>
>>>
>>>
>


From andrea.aime at geo-solutions.it  Sun Apr 14 15:37:07 2013
From: andrea.aime at geo-solutions.it (Andrea Aime)
Date: Sun, 14 Apr 2013 17:37:07 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: 
References: 
Message-ID: 

On Tue, Apr 9, 2013 at 3:02 PM, Laurent Bourg?s
wrote:

> Dear Java2D members,
>
> Could someone review the following webrev concerning Java2D Pisces to
> enhance its performance and reduce its memory footprint (RendererContext
> stored in thread local or concurrent queue):
> http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/
>
> FYI I fixed file headers in this patch and signed my OCA 3 weeks ago.
>
> Remaining work:
> - cleanup (comments ...)
> - statistics to perform auto-tuning
> - cache / memory cleanup (SoftReference ?): use hints or System properties
> to adapt it to use cases
> - another problem: fix clipping performance in Dasher / Stroker for
> segments out of bounds
>
> Could somebody support me ? ie help me working on these tasks or just to
> discuss on Pisces algorithm / implementation ?
>

Hi,
I would like to express my support for this patch.
Given that micro-benchmarks have already been run, I took the patch for a
spin in a large, real world benchmark instead,
the OSGeo WMS Shootout 2010 benchmark, for which you can see the results
here:
http://www.slideshare.net/gatewaygeomatics.com/wms-performance-shootout-2010

The presentation is long, but suffice it to say all Java based
implementations took quite the beating due to the
poor scalability of Ductus with antialiased rendering of vector data (for
an executive summary just look
at slide 27 and slide 66, where GeoServer, Oracle MapViewer and
Constellation SDI were the
Java based ones)

I took the same tests and run them again on my machine (different hardware
than the tests, don't try to compare
the absolute values), using Oracle JDK 1.7.0_17, OpenJDK 8 (a checkout a
couple of weeks old) and the
same, but with Laurent's patches applied.
Here are the results, throughput (in maps generated per second) with the
load generator (JMeter) going
up from one client to 64 concurrent clients:

   *Threads* *JDK 1.7.0_17* *OpenJDK 8, vanilla* *OpenJDK 8 + pisces
renderer improvements* *Pisces renderer performance gain, %*  1 13,97 12,43
13,03 4,75%  2 22,08 20,60 20,77 0,81%  4 34,36 33,15 33,36 0,62%  8 39,39
40,51 41,71 2,96%  16 40,61 44,57 46,98 5,39%  32 41,41 44,73 48,16 7,66%
64 37,09 42,19 45,28 7,32%

Well, first of all, congratulations to the JDK developers, don't know what
changed in JDK 8, but
GeoServer seems to like it quite a bit :-).
That said, Laurent's patch also gives a visible boost, especially when
several concurrent clients are
asking for the maps.

Mind, as I said, this is no micro-benchmark, it is a real application
loading doing a lot of I/O
(from the operating system file cache), other processing before the data
reaches the rendering
pipeline, and then has to PNG encode the output BufferedImage (PNG encoding
being rather
expensive), so getting this speedup from just a change in the rendering
pipeline is significant.

Long story short... personally I'd be very happy if this patch was going to
be integrated in Java 8 :-)

Cheers
Andrea

-- 
==
GeoServer training in Milan, 6th & 7th June 2013!  Visit
http://geoserver.geo-solutions.it for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bourges.laurent at gmail.com  Mon Apr 15 10:01:54 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Mon, 15 Apr 2013 12:01:54 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: 
References: 
	
Message-ID: 

Jim, Andrea,

I updated MapBench to provide test statistics (avg, median, stddev, rms,
med + stddev, min, max) and CSV output (tab separator):
http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench/


Here are the results (OpenJDK8 Ref vs Patched):
http://jmmc.fr/~bourgesl/share/java2d-pisces/ref_det.log
http://jmmc.fr/~bourgesl/share/java2d-pisces/patch_det.log

   test threads ops Tavg Tmed stdDev rms Med+Stddev min max  boulder_17 1 20
180,22% 181,08% 1186,01% 181,17% 185,92% 176,35% 170,36%  boulder_17 2 20
183,15% 183,80% 162,68% 183,78% 183,17% 174,01% 169,89%  boulder_17 4 20
216,62% 218,03% 349,31% 218,87% 226,68% 172,15% 167,54%  shp_alllayers_47 1
20 243,90% 244,86% 537,92% 244,87% 246,39% 240,64% 231,00%  shp_alllayers_47
2 20 286,42% 287,07% 294,87% 287,07% 287,23% 277,19% 272,23%
shp_alllayers_47 4 20 303,08% 302,15% 168,19% 301,90% 295,90% 462,70%
282,41%

PATCH:
   test threads ops Tavg Tmed stdDev rms Med+Stddev min max  boulder_17 1 20
110,196 109,244 0,529 109,246 109,773 108,197 129,327  boulder_17 2 40
127,916 127,363 3,899 127,423 131,262 125,262 151,561  boulder_17 4 80
213,085 212,268 14,988 212,796 227,256 155,512 334,407  shp_alllayers_47 1
20 1139,452 1134,858 5,971 1134,873 1140,829 1125,859 1235,746
shp_alllayers_47 2 40 1306,889 1304,598 28,157 1304,902 1332,755 1280,49
1420,351  shp_alllayers_47 4 80 2296,487 2303,81 112,816 2306,57 2416,626
1390,31 2631,455

REF:
   test threads ops Tavg Tmed stdDev rms Med+Stddev min max  boulder_17 1 20
198,591 197,816 6,274 197,916 204,091 190,805 220,319  boulder_17 2 40
234,272 234,09 6,343 234,176 240,433 217,967 257,485  boulder_17 4 80
461,579 462,8 52,354 465,751 515,153 267,712 560,254  shp_alllayers_47 1 20
2779,133 2778,823 32,119 2779,009 2810,943 2709,285 2854,557
shp_alllayers_47 2 40 3743,255 3745,111 83,027 3746,031 3828,138 3549,364
3866,612  shp_alllayers_47 4 80 6960,23 6960,948 189,75 6963,533 7150,698
6432,945 7431,541
Linux 64 server vm
JVM: -Xms128m -Xmx128m (low mem)

Laurent

2013/4/14 Andrea Aime 

> On Tue, Apr 9, 2013 at 3:02 PM, Laurent Bourg?s  > wrote:
>
>> Dear Java2D members,
>>
>> Could someone review the following webrev concerning Java2D Pisces to
>> enhance its performance and reduce its memory footprint (RendererContext
>> stored in thread local or concurrent queue):
>> http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/
>>
>> FYI I fixed file headers in this patch and signed my OCA 3 weeks ago.
>>
>> Remaining work:
>> - cleanup (comments ...)
>> - statistics to perform auto-tuning
>> - cache / memory cleanup (SoftReference ?): use hints or System
>> properties to adapt it to use cases
>> - another problem: fix clipping performance in Dasher / Stroker for
>> segments out of bounds
>>
>> Could somebody support me ? ie help me working on these tasks or just to
>> discuss on Pisces algorithm / implementation ?
>>
>
> Hi,
> I would like to express my support for this patch.
> Given that micro-benchmarks have already been run, I took the patch for a
> spin in a large, real world benchmark instead,
> the OSGeo WMS Shootout 2010 benchmark, for which you can see the results
> here:
>
> http://www.slideshare.net/gatewaygeomatics.com/wms-performance-shootout-2010
>
> The presentation is long, but suffice it to say all Java based
> implementations took quite the beating due to the
> poor scalability of Ductus with antialiased rendering of vector data (for
> an executive summary just look
> at slide 27 and slide 66, where GeoServer, Oracle MapViewer and
> Constellation SDI were the
> Java based ones)
>
> I took the same tests and run them again on my machine (different hardware
> than the tests, don't try to compare
> the absolute values), using Oracle JDK 1.7.0_17, OpenJDK 8 (a checkout a
> couple of weeks old) and the
> same, but with Laurent's patches applied.
> Here are the results, throughput (in maps generated per second) with the
> load generator (JMeter) going
> up from one client to 64 concurrent clients:
>
>    *Threads* *JDK 1.7.0_17* *OpenJDK 8, vanilla* *OpenJDK 8 + pisces
> renderer improvements* *Pisces renderer performance gain, %*  1 13,97
> 12,43 13,03 4,75%  2 22,08 20,60 20,77 0,81%  4 34,36 33,15 33,36 0,62%  8
> 39,39 40,51 41,71 2,96%  16 40,61 44,57 46,98 5,39%  32 41,41 44,73 48,16
> 7,66%  64 37,09 42,19 45,28 7,32%
>
> Well, first of all, congratulations to the JDK developers, don't know what
> changed in JDK 8, but
> GeoServer seems to like it quite a bit :-).
> That said, Laurent's patch also gives a visible boost, especially when
> several concurrent clients are
> asking for the maps.
>
> Mind, as I said, this is no micro-benchmark, it is a real application
> loading doing a lot of I/O
> (from the operating system file cache), other processing before the data
> reaches the rendering
> pipeline, and then has to PNG encode the output BufferedImage (PNG
> encoding being rather
> expensive), so getting this speedup from just a change in the rendering
> pipeline is significant.
>
> Long story short... personally I'd be very happy if this patch was going
> to be integrated in Java 8 :-)
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer training in Milan, 6th & 7th June 2013!  Visit
> http://geoserver.geo-solutions.it for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From andrew.brygin at oracle.com  Mon Apr 15 12:58:45 2013
From: andrew.brygin at oracle.com (andrew.brygin at oracle.com)
Date: Mon, 15 Apr 2013 12:58:45 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 8005930: [lcms] ColorConvertOp:
	Alpha channel is not	transferred from source to destination.
Message-ID: <20130415125936.283BF482E9@hg.openjdk.java.net>

Changeset: b59b1f5a98dd
Author:    bae
Date:      2013-04-15 16:57 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b59b1f5a98dd

8005930: [lcms] ColorConvertOp: Alpha channel is not transferred from source to destination.
Reviewed-by: prr

! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
+ test/sun/java2d/cmm/ColorConvertOp/AlphaTest.java



From andrew.brygin at oracle.com  Mon Apr 15 14:16:34 2013
From: andrew.brygin at oracle.com (andrew.brygin at oracle.com)
Date: Mon, 15 Apr 2013 14:16:34 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 8011622: Use lcms as the default
	color management	module in jdk8
Message-ID: <20130415141708.EC5B9482EF@hg.openjdk.java.net>

Changeset: 03ee8c648624
Author:    bae
Date:      2013-04-15 18:10 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/03ee8c648624

8011622: Use lcms as the default color management module in jdk8
Reviewed-by: prr, vadim

! make/sun/cmm/Makefile
! make/sun/cmm/kcms/Makefile
! make/sun/cmm/lcms/Makefile
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyIntoClasses.gmk
+ src/share/classes/sun/java2d/cmm/CMMServiceProvider.java
! src/share/classes/sun/java2d/cmm/CMSManager.java
! src/share/classes/sun/java2d/cmm/lcms/LCMS.java
+ src/share/classes/sun/java2d/cmm/lcms/LcmsServiceProvider.java
+ src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.CMMServiceProvider
- src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM



From patrick at reini.net  Tue Apr 16 12:15:28 2013
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 16 Apr 2013 14:15:28 +0200
Subject: [OpenJDK 2D-Dev] Fix proposal for UnixPrintServiceLookup not
	returning consistent values
Message-ID: <921DCFDE-B4B9-4E51-A95E-6439111A7AC4@reini.net>

Hi there,

We recently found the problem in the Linux OpenJDK that the resulting PrintService implementations returned by PrintServiceLookup.lookupPrintServices(DocFlavor, AttributeSet) does not consistently return equal results.

Printer setup:
We got 2 printers A and B, where A is also the default printer.

If we lookup all printer services not passing any values to lookupPrintServices() we get all of type IPPPrintService. Doing the same using a PrinterName attribute we get UnixPrintService for the non default printer, which in our case does not support any paper trays...

I was able to track down the problem within the UnixPrintServiceLookup class. I would propose to loop over all print services returned by the method getPrintServices() internally to lookup the correct printer if the default printer does not match in the first place.

Cheers Patrick




From james.graham at oracle.com  Tue Apr 16 21:16:47 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 16 Apr 2013 14:16:47 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: 
References: 
	
	
Message-ID: <516DBFBF.20504@oracle.com>

If I'm reading this correctly, your patch is faster even for a single 
thread?  That's great news.

One of the problems we've had with replacing Ductus is that it has been 
faster in a single thread situation than the open source versions we've 
created.  One of its drawbacks is that it had been designed to take 
advantage of some AA-accelerating hardware that never came to be.  With 
the accelerator it would have been insanely fast, but hardware went in a 
different direction.  The problem was that this early design goal caused 
the entire library to be built around an abstraction layer that allowed 
for a single "tile producer" internally (because there would be only one 
- insanely fast - hardware chip available) and the software version of 
the abstraction layer thus had a lot of native "static" data structures 
(there's only one of me, right?) that prevented MT access.  It was 
probably solvable, but I'd be happier if someone could come up with a 
faster rasterizer, imagining that there must have been some sort of 
advancements in the nearly 2 decades since the original was written.

If I'm misinterpreting and single thread is still slower than Ductus (or 
if it is still slower on some other platforms), then .

Also, this is with the Java version, right?  We got a decent 2x speedup 
in FX by porting the version of Open Pisces that you started with to C 
code (all except on Linux where we couldn't find the right gcc options 
to make it faster than Hotspot).  So, we have yet to investigate a 
native version in the JDK which might provide even more gains...

			...jim

On 4/15/13 3:01 AM, Laurent Bourg?s wrote:
> Jim, Andrea,
>
> I updated MapBench to provide test statistics (avg, median, stddev, rms,
> med + stddev, min, max) and CSV output (tab separator):
> http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench/
> 
>
>
> Here are the results (OpenJDK8 Ref vs Patched):
> http://jmmc.fr/~bourgesl/share/java2d-pisces/ref_det.log
> http://jmmc.fr/~bourgesl/share/java2d-pisces/patch_det.log
>
> test 	threads 	ops 	Tavg 	Tmed 	stdDev 	rms 	Med+Stddev 	min 	max
> boulder_17 	1 	20 	180,22% 	181,08% 	1186,01% 	181,17% 	185,92%
> 176,35% 	170,36%
> boulder_17 	2 	20 	183,15% 	183,80% 	162,68% 	183,78% 	183,17%
> 174,01% 	169,89%
> boulder_17 	4 	20 	216,62% 	218,03% 	349,31% 	218,87% 	226,68%
> 172,15% 	167,54%
> shp_alllayers_47 	1 	20 	243,90% 	244,86% 	537,92% 	244,87% 	246,39%
> 240,64% 	231,00%
> shp_alllayers_47 	2 	20 	286,42% 	287,07% 	294,87% 	287,07% 	287,23%
> 277,19% 	272,23%
> shp_alllayers_47 	4 	20 	303,08% 	302,15% 	168,19% 	301,90% 	295,90%
> 462,70% 	282,41%
>
>
>
> PATCH:
> test 	threads 	ops 	Tavg 	Tmed 	stdDev 	rms 	Med+Stddev 	min 	max
> boulder_17 	1 	20 	110,196 	109,244 	0,529 	109,246 	109,773 	108,197
> 129,327
> boulder_17 	2 	40 	127,916 	127,363 	3,899 	127,423 	131,262 	125,262
> 151,561
> boulder_17 	4 	80 	213,085 	212,268 	14,988 	212,796 	227,256 	155,512
> 334,407
> shp_alllayers_47 	1 	20 	1139,452 	1134,858 	5,971 	1134,873 	1140,829
> 1125,859 	1235,746
> shp_alllayers_47 	2 	40 	1306,889 	1304,598 	28,157 	1304,902
> 1332,755 	1280,49 	1420,351
> shp_alllayers_47 	4 	80 	2296,487 	2303,81 	112,816 	2306,57 	2416,626
> 1390,31 	2631,455
>
>
>
> REF:
> test 	threads 	ops 	Tavg 	Tmed 	stdDev 	rms 	Med+Stddev 	min 	max
> boulder_17 	1 	20 	198,591 	197,816 	6,274 	197,916 	204,091 	190,805
> 220,319
> boulder_17 	2 	40 	234,272 	234,09 	6,343 	234,176 	240,433 	217,967
> 257,485
> boulder_17 	4 	80 	461,579 	462,8 	52,354 	465,751 	515,153 	267,712
> 560,254
> shp_alllayers_47 	1 	20 	2779,133 	2778,823 	32,119 	2779,009
> 2810,943 	2709,285 	2854,557
> shp_alllayers_47 	2 	40 	3743,255 	3745,111 	83,027 	3746,031
> 3828,138 	3549,364 	3866,612
> shp_alllayers_47 	4 	80 	6960,23 	6960,948 	189,75 	6963,533 	7150,698
> 6432,945 	7431,541
>
>
> Linux 64 server vm
> JVM: -Xms128m -Xmx128m (low mem)
>
> Laurent
>
> 2013/4/14 Andrea Aime  >
>
>     On Tue, Apr 9, 2013 at 3:02 PM, Laurent Bourg?s
>     > wrote:
>
>         Dear Java2D members,
>
>         Could someone review the following webrev concerning Java2D
>         Pisces to enhance its performance and reduce its memory
>         footprint (RendererContext stored in thread local or concurrent
>         queue):
>         http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/
>         
>
>         FYI I fixed file headers in this patch and signed my OCA 3 weeks
>         ago.
>
>         Remaining work:
>         - cleanup (comments ...)
>         - statistics to perform auto-tuning
>         - cache / memory cleanup (SoftReference ?): use hints or System
>         properties to adapt it to use cases
>         - another problem: fix clipping performance in Dasher / Stroker
>         for segments out of bounds
>
>         Could somebody support me ? ie help me working on these tasks or
>         just to discuss on Pisces algorithm / implementation ?
>
>
>     Hi,
>     I would like to express my support for this patch.
>     Given that micro-benchmarks have already been run, I took the patch
>     for a spin in a large, real world benchmark instead,
>     the OSGeo WMS Shootout 2010 benchmark, for which you can see the
>     results here:
>     http://www.slideshare.net/gatewaygeomatics.com/wms-performance-shootout-2010
>
>     The presentation is long, but suffice it to say all Java based
>     implementations took quite the beating due to the
>     poor scalability of Ductus with antialiased rendering of vector data
>     (for an executive summary just look
>     at slide 27 and slide 66, where GeoServer, Oracle MapViewer and
>     Constellation SDI were the
>     Java based ones)
>
>     I took the same tests and run them again on my machine (different
>     hardware than the tests, don't try to compare
>     the absolute values), using Oracle JDK 1.7.0_17, OpenJDK 8 (a
>     checkout a couple of weeks old) and the
>     same, but with Laurent's patches applied.
>     Here are the results, throughput (in maps generated per second) with
>     the load generator (JMeter) going
>     up from one client to 64 concurrent clients:
>
>     *Threads* 	*JDK 1.7.0_17* 	*OpenJDK 8, vanilla* 	*OpenJDK 8 + pisces
>     renderer improvements* 	*Pisces renderer performance gain, %*
>     1 	13,97 	12,43 	13,03 	4,75%
>     2 	22,08 	20,60 	20,77 	0,81%
>     4 	34,36 	33,15 	33,36 	0,62%
>     8 	39,39 	40,51 	41,71 	2,96%
>     16 	40,61 	44,57 	46,98 	5,39%
>     32 	41,41 	44,73 	48,16 	7,66%
>     64 	37,09 	42,19 	45,28 	7,32%
>
>
>     Well, first of all, congratulations to the JDK developers, don't
>     know what changed in JDK 8, but
>     GeoServer seems to like it quite a bit :-).
>     That said, Laurent's patch also gives a visible boost, especially
>     when several concurrent clients are
>     asking for the maps.
>
>     Mind, as I said, this is no micro-benchmark, it is a real
>     application loading doing a lot of I/O
>     (from the operating system file cache), other processing before the
>     data reaches the rendering
>     pipeline, and then has to PNG encode the output BufferedImage (PNG
>     encoding being rather
>     expensive), so getting this speedup from just a change in the
>     rendering pipeline is significant.
>
>     Long story short... personally I'd be very happy if this patch was
>     going to be integrated in Java 8 :-)
>
>     Cheers
>     Andrea
>
>     --
>     ==
>     GeoServer training in Milan, 6th & 7th June 2013!  Visit
>     http://geoserver.geo-solutions.it
>      for more information.
>     ==
>
>     Ing. Andrea Aime
>     @geowolf
>     Technical Lead
>
>     GeoSolutions S.A.S.
>     Via Poggio alle Viti 1187
>     55054  Massarosa (LU)
>     Italy
>     phone: +39 0584 962313
>     fax: +39 0584 1660272
>     mob: +39  339 8844549
>
>     http://www.geo-solutions.it
>     http://twitter.com/geosolutions_it
>
>     -------------------------------------------------------
>
>


From anton.litvinov at oracle.com  Wed Apr 17 12:53:08 2013
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Wed, 17 Apr 2013 16:53:08 +0400
Subject: [OpenJDK 2D-Dev] [8] Review request for 8007642: Media Names on
 Java Print Do Not Match the Printer's and Confuse Users
In-Reply-To: <5155EAE1.8090208@oracle.com>
References: <51152343.8060303@oracle.com> <512634FC.8060504@oracle.com>
	<513D98BD.8030201@oracle.com> <5155EAE1.8090208@oracle.com>
Message-ID: <516E9B34.7080200@oracle.com>

Hello Jennifer,

Thank you very much for the review of this fix. For reproduction of this 
bug and testing of the fix the printer "PrimoPDF" with its driver 
"PrimoPDF" was used. This printer is a virtual printer which generates 
PDF files as a result of printing jobs and which can be downloaded at 
the URL (http://www.primopdf.com). Such a printer was selected for 
testing, because it supports the paper size "11 x 17" in inches, with 
which the bug was experienced by a user according to the bug report.

Also I was able to observe a similar situation with the printers: 
"Microsoft XPS Document Writer", "Xerox WorkCentre 4250 GPD PS" but on 
paper sizes different from "11 x 17". For example, if the printer "Xerox 
WorkCentre 4250 GPD PS" is used, JDK interprets the paper size "Postcard 
(100 x 148 mm)" as "Postcard (JIS)" and, when algorithm of the method 
"sun.print.Win32PrintService.getMediaSizes" encounters the paper size 
"Japanese Postcard", it interprets it as "Postcard (JIS)" again, which 
leaves just one media size "Postcard (JIS)" from 2 in Java 
cross-platform Page Setup and Print dialogs. I think that this situation 
is similar to the case with "11 x 17" paper size, because some user can 
also be willing to see exactly "Postcard (100 x 148 mm)" media size in 
the mentioned Java dialogs, where it will be absent, whoever this fix 
still will not allow "Postcard (100 x 148 mm)" to be displayed.

Thank you,
Anton

On 3/29/2013 11:26 PM, Jennifer Godinez wrote:
> Hi Anton,
>
> What printer and printer driver version did you use to test your fix?
> Thanks.
>
> Jennifer
>
> On 3/11/2013 1:41 AM, Anton Litvinov wrote:
>> Hello,
>>
>> Please review the following fix. This is the second reminder message. 
>> Please take into account that the original review request was sent 
>> more than 1 month ago and no response has been received yet.
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>
>> Thank you,
>> Anton
>>
>> On 2/21/2013 6:53 PM, Anton Litvinov wrote:
>>> Hello,
>>>
>>> I am sorry for inconvenience. This is a reminder message. I am still 
>>> interested in reception of the response to this review request and 
>>> just want to be sure that it is not lost on the mail alias's archive.
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 2/8/2013 8:09 PM, Anton Litvinov wrote:
>>>> Hello,
>>>>
>>>> Please review the following fix for a bug.
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>>>
>>>> The bug consists in the fact that Java cross-platform Page Setup 
>>>> and Print dialogs do not always list all media sizes supported by a 
>>>> printer. The fix is based on addition of dynamic creation of new 
>>>> media names of the type "sun.print.Win32MediaSize" based on paper 
>>>> names received from Windows API function with corresponding media 
>>>> sizes of the type "javax.print.attribute.standard.MediaSize" for 
>>>> the case, when the printer's media size name, which is being 
>>>> analyzed in "sun.print.Win32PrintService.initMedia" method, is not 
>>>> added to the final list of media sizes supported by the printer 
>>>> because of an already existing duplicate in that list. In such a 
>>>> case the printer's paper size matches with one of the media sizes 
>>>> registered in JDK, while the paper size ID does not match with any 
>>>> ID known to JDK.
>>>>
>>>> Also the code in "Win32PrintService.findWin32Media" method was 
>>>> altered to allow three cases from "switch" block to work as 
>>>> expected, because currently they never match with "dmIndex" value, 
>>>> since it is always less then "dmPaperToPrintService.length" under 
>>>> "if" statement.
>>>>
>>>> Thank you,
>>>> Anton
>>>
>>
>



From jennifer.godinez at oracle.com  Wed Apr 17 16:49:31 2013
From: jennifer.godinez at oracle.com (Jennifer Godinez)
Date: Wed, 17 Apr 2013 09:49:31 -0700
Subject: [OpenJDK 2D-Dev] [8] Review request for 8007642: Media Names on
 Java Print Do Not Match the Printer's and Confuse Users
In-Reply-To: <516E9B34.7080200@oracle.com>
References: <51152343.8060303@oracle.com> <512634FC.8060504@oracle.com>
	<513D98BD.8030201@oracle.com> <5155EAE1.8090208@oracle.com>
	<516E9B34.7080200@oracle.com>
Message-ID: <516ED29B.6040503@oracle.com>

Thanks Anton.  I will test your fix and let you know.

Jennifer

On 4/17/2013 5:53 AM, Anton Litvinov wrote:
> Hello Jennifer,
>
> Thank you very much for the review of this fix. For reproduction of 
> this bug and testing of the fix the printer "PrimoPDF" with its driver 
> "PrimoPDF" was used. This printer is a virtual printer which generates 
> PDF files as a result of printing jobs and which can be downloaded at 
> the URL (http://www.primopdf.com). Such a printer was selected for 
> testing, because it supports the paper size "11 x 17" in inches, with 
> which the bug was experienced by a user according to the bug report.
>
> Also I was able to observe a similar situation with the printers: 
> "Microsoft XPS Document Writer", "Xerox WorkCentre 4250 GPD PS" but on 
> paper sizes different from "11 x 17". For example, if the printer 
> "Xerox WorkCentre 4250 GPD PS" is used, JDK interprets the paper size 
> "Postcard (100 x 148 mm)" as "Postcard (JIS)" and, when algorithm of 
> the method "sun.print.Win32PrintService.getMediaSizes" encounters the 
> paper size "Japanese Postcard", it interprets it as "Postcard (JIS)" 
> again, which leaves just one media size "Postcard (JIS)" from 2 in 
> Java cross-platform Page Setup and Print dialogs. I think that this 
> situation is similar to the case with "11 x 17" paper size, because 
> some user can also be willing to see exactly "Postcard (100 x 148 mm)" 
> media size in the mentioned Java dialogs, where it will be absent, 
> whoever this fix still will not allow "Postcard (100 x 148 mm)" to be 
> displayed.
>
> Thank you,
> Anton
>
> On 3/29/2013 11:26 PM, Jennifer Godinez wrote:
>> Hi Anton,
>>
>> What printer and printer driver version did you use to test your fix?
>> Thanks.
>>
>> Jennifer
>>
>> On 3/11/2013 1:41 AM, Anton Litvinov wrote:
>>> Hello,
>>>
>>> Please review the following fix. This is the second reminder 
>>> message. Please take into account that the original review request 
>>> was sent more than 1 month ago and no response has been received yet.
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 2/21/2013 6:53 PM, Anton Litvinov wrote:
>>>> Hello,
>>>>
>>>> I am sorry for inconvenience. This is a reminder message. I am 
>>>> still interested in reception of the response to this review 
>>>> request and just want to be sure that it is not lost on the mail 
>>>> alias's archive.
>>>>
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 2/8/2013 8:09 PM, Anton Litvinov wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following fix for a bug.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>>>>
>>>>> The bug consists in the fact that Java cross-platform Page Setup 
>>>>> and Print dialogs do not always list all media sizes supported by 
>>>>> a printer. The fix is based on addition of dynamic creation of new 
>>>>> media names of the type "sun.print.Win32MediaSize" based on paper 
>>>>> names received from Windows API function with corresponding media 
>>>>> sizes of the type "javax.print.attribute.standard.MediaSize" for 
>>>>> the case, when the printer's media size name, which is being 
>>>>> analyzed in "sun.print.Win32PrintService.initMedia" method, is not 
>>>>> added to the final list of media sizes supported by the printer 
>>>>> because of an already existing duplicate in that list. In such a 
>>>>> case the printer's paper size matches with one of the media sizes 
>>>>> registered in JDK, while the paper size ID does not match with any 
>>>>> ID known to JDK.
>>>>>
>>>>> Also the code in "Win32PrintService.findWin32Media" method was 
>>>>> altered to allow three cases from "switch" block to work as 
>>>>> expected, because currently they never match with "dmIndex" value, 
>>>>> since it is always less then "dmPaperToPrintService.length" under 
>>>>> "if" statement.
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>
>>>
>>
>



From patrick at reini.net  Wed Apr 17 20:11:01 2013
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 17 Apr 2013 22:11:01 +0200
Subject: [OpenJDK 2D-Dev] Fix proposal for UnixPrintServiceLookup not
 returning consistent values
In-Reply-To: <921DCFDE-B4B9-4E51-A95E-6439111A7AC4@reini.net>
References: <921DCFDE-B4B9-4E51-A95E-6439111A7AC4@reini.net>
Message-ID: <1366229461.2858.4.camel@wsccuw01.ccuw.ch>

On Tue, 2013-04-16 at 14:15 +0200, Patrick Reinhart wrote:

Here's the link to suggested fix:

http://reinharts.dyndns.org/webrev/

Cheers Patrick 



From bourges.laurent at gmail.com  Wed Apr 17 20:14:13 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Wed, 17 Apr 2013 22:14:13 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: <516DBFBF.20504@oracle.com>
References: 
	
	
	<516DBFBF.20504@oracle.com>
Message-ID: 

Jim,

thanks for having some interest for my efforts !
As I got almost no feedback, I felt quite disappointed and was thinking
that improving pisces was not important ...

Here are ductus results and comparison (open office format):
http://jmmc.fr/~bourgesl/share/java2d-pisces/ductus_det.log
http://jmmc.fr/~bourgesl/share/java2d-pisces/compareRef_Patch.ods

   test threads ops Tavg Tmed stdDev rms *Med+Stddev* min max  boulder_17 1
20 73,92% 69,34% 27,98% 69,34% *69,14%* 69,81% 146,89%  boulder_17 2 20
110,86% 110,48% 613,80% 112,01% *125,43%* 94,71% 136,35%  boulder_17 4 20
135,28% 135,86% 226,61% 136,46% *141,85%* 125,14% 111,32%  shp_alllayers_47
1 20 82,25% 82,49% 47,50% 82,48% *82,30%* 82,64% 78,08%  shp_alllayers_47 2
20 115,87% 115,67% 315,45% 115,85% *119,89%* 109,33% 128,71%
shp_alllayers_47 4 20 218,59% 218,76% 169,38% 218,65% *216,45%* 220,17%
206,17%
Ductus vs Patch
   *1* *80,74%*  *2* *120,69%*  *4* *205,92%*
Reminder: Ref vs Patch
   *1* *237,71%*  *2* *271,68%*  *4* *286,15%*

Note: I only have 2 cores + HT on my laptop and do not test with more
threads (64 like andrea).

2013/4/16 Jim Graham 

> If I'm reading this correctly, your patch is faster even for a single
> thread?  That's great news.
>

Not yet, but ductus is now only 20% faster than my patch and 20% and 2x
slower with 2 and 4 threads :
I still hope to beat it applying few more optimizations:
- Renderer.ScanLine iterator / Renderer.endRendering can be improved
- avoid few more array zero fill (reset) if possible
- adding statistics to better set initial array sizes ...
- use SunGraphics2D to hold an hard reference (temporarly) on
RendererContext (to avoid many ThreadLocal.get())
- cache eviction (WeakReference or SoftReference) ?

Why not use divide and conquer (thread pool) to boost single thread
rendering if the machine has more cpu cores ?
It would be helpful if the AATileGenerator has access to SunGraphics2D to
get rendering hints or share variables (cache ...)

For the moment, I did not modify the algorithms itself but I will do it to
enhance clipping (dasher segments / stroker) ...


> One of the problems we've had with replacing Ductus is that it has been
> faster in a single thread situation than the open source versions we've
> created.  One of its drawbacks is that it had been designed to take
> advantage of some AA-accelerating hardware that never came to be.  With the
> accelerator it would have been insanely fast, but hardware went in a
> different direction.  The problem was that this early design goal caused
> the entire library to be built around an abstraction layer that allowed for
> a single "tile producer" internally (because there would be only one -
> insanely fast - hardware chip available) and the software version of the
> abstraction layer thus had a lot of native "static" data structures
> (there's only one of me, right?) that prevented MT access.  It was probably
> solvable, but I'd be happier if someone could come up with a faster
> rasterizer, imagining that there must have been some sort of advancements
> in the nearly 2 decades since the original was written.
>
> If I'm misinterpreting and single thread is still slower than Ductus (or
> if it is still slower on some other platforms), then .
>

Not yet: slower than ductus by 20% but faster than current pisces by 2
times !


> Also, this is with the Java version, right?


Yes, my patch is pure java given as webrev:
        http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/


> We got a decent 2x speedup in FX by porting the version of Open Pisces
> that you started with to C code (all except on Linux where we couldn't find
> the right gcc options to make it faster than Hotspot).  So, we have yet to
> investigate a native version in the JDK which might provide even more
> gains...
>

Personally I prefer working on java code as hotspot can perform so much
optimizations for free and no pointers to deal with and more important:
concurrent primitives (thread local, collections) !

Laurent


>
> On 4/15/13 3:01 AM, Laurent Bourg?s wrote:
>
>> Jim, Andrea,
>>
>> I updated MapBench to provide test statistics (avg, median, stddev, rms,
>> med + stddev, min, max) and CSV output (tab separator):
>> http://jmmc.fr/~bourgesl/**share/java2d-pisces/MapBench/
>> 
>> >
>>
>>
>>
>> Here are the results (OpenJDK8 Ref vs Patched):
>> http://jmmc.fr/~bourgesl/**share/java2d-pisces/ref_det.**log
>> http://jmmc.fr/~bourgesl/**share/java2d-pisces/patch_det.**log
>>
>> test    threads         ops     Tavg    Tmed    stdDev  rms
>> Med+Stddev      min     max
>> boulder_17      1       20      180,22%         181,08%         1186,01%
>>        181,17%         185,92%
>> 176,35%         170,36%
>> boulder_17      2       20      183,15%         183,80%         162,68%
>>       183,78%         183,17%
>> 174,01%         169,89%
>> boulder_17      4       20      216,62%         218,03%         349,31%
>>       218,87%         226,68%
>> 172,15%         167,54%
>> shp_alllayers_47        1       20      243,90%         244,86%
>> 537,92%         244,87%         246,39%
>> 240,64%         231,00%
>> shp_alllayers_47        2       20      286,42%         287,07%
>> 294,87%         287,07%         287,23%
>> 277,19%         272,23%
>> shp_alllayers_47        4       20      303,08%         302,15%
>> 168,19%         301,90%         295,90%
>> 462,70%         282,41%
>>
>>
>>
>> PATCH:
>> test    threads         ops     Tavg    Tmed    stdDev  rms
>> Med+Stddev      min     max
>> boulder_17      1       20      110,196         109,244         0,529
>> 109,246         109,773         108,197
>> 129,327
>> boulder_17      2       40      127,916         127,363         3,899
>> 127,423         131,262         125,262
>> 151,561
>> boulder_17      4       80      213,085         212,268         14,988
>>  212,796         227,256         155,512
>> 334,407
>> shp_alllayers_47        1       20      1139,452        1134,858
>>  5,971   1134,873        1140,829
>> 1125,859        1235,746
>> shp_alllayers_47        2       40      1306,889        1304,598
>>  28,157  1304,902
>> 1332,755        1280,49         1420,351
>> shp_alllayers_47        4       80      2296,487        2303,81
>> 112,816         2306,57         2416,626
>> 1390,31         2631,455
>>
>>
>>
>> REF:
>> test    threads         ops     Tavg    Tmed    stdDev  rms
>> Med+Stddev      min     max
>> boulder_17      1       20      198,591         197,816         6,274
>> 197,916         204,091         190,805
>> 220,319
>> boulder_17      2       40      234,272         234,09  6,343   234,176
>>       240,433         217,967
>> 257,485
>> boulder_17      4       80      461,579         462,8   52,354  465,751
>>       515,153         267,712
>> 560,254
>> shp_alllayers_47        1       20      2779,133        2778,823
>>  32,119  2779,009
>> 2810,943        2709,285        2854,557
>> shp_alllayers_47        2       40      3743,255        3745,111
>>  83,027  3746,031
>> 3828,138        3549,364        3866,612
>> shp_alllayers_47        4       80      6960,23         6960,948
>>  189,75  6963,533        7150,698
>> 6432,945        7431,541
>>
>>
>> Linux 64 server vm
>> JVM: -Xms128m -Xmx128m (low mem)
>>
>> Laurent
>>
>> 2013/4/14 Andrea Aime > >>
>>
>>     On Tue, Apr 9, 2013 at 3:02 PM, Laurent Bourg?s
>>
>>     >>
>> wrote:
>>
>>         Dear Java2D members,
>>
>>         Could someone review the following webrev concerning Java2D
>>         Pisces to enhance its performance and reduce its memory
>>         footprint (RendererContext stored in thread local or concurrent
>>         queue):
>>         http://jmmc.fr/~bourgesl/**share/java2d-pisces/webrev-1/
>>         
>> >
>>
>>
>>         FYI I fixed file headers in this patch and signed my OCA 3 weeks
>>         ago.
>>
>>         Remaining work:
>>         - cleanup (comments ...)
>>         - statistics to perform auto-tuning
>>         - cache / memory cleanup (SoftReference ?): use hints or System
>>         properties to adapt it to use cases
>>         - another problem: fix clipping performance in Dasher / Stroker
>>         for segments out of bounds
>>
>>         Could somebody support me ? ie help me working on these tasks or
>>         just to discuss on Pisces algorithm / implementation ?
>>
>>
>>     Hi,
>>     I would like to express my support for this patch.
>>     Given that micro-benchmarks have already been run, I took the patch
>>     for a spin in a large, real world benchmark instead,
>>     the OSGeo WMS Shootout 2010 benchmark, for which you can see the
>>     results here:
>>     http://www.slideshare.net/**gatewaygeomatics.com/wms-**
>> performance-shootout-2010
>>
>>     The presentation is long, but suffice it to say all Java based
>>     implementations took quite the beating due to the
>>     poor scalability of Ductus with antialiased rendering of vector data
>>     (for an executive summary just look
>>     at slide 27 and slide 66, where GeoServer, Oracle MapViewer and
>>     Constellation SDI were the
>>     Java based ones)
>>
>>     I took the same tests and run them again on my machine (different
>>     hardware than the tests, don't try to compare
>>     the absolute values), using Oracle JDK 1.7.0_17, OpenJDK 8 (a
>>     checkout a couple of weeks old) and the
>>     same, but with Laurent's patches applied.
>>     Here are the results, throughput (in maps generated per second) with
>>     the load generator (JMeter) going
>>     up from one client to 64 concurrent clients:
>>
>>     *Threads*   *JDK 1.7.0_17*  *OpenJDK 8, vanilla*    *OpenJDK 8 +
>> pisces
>>     renderer improvements*      *Pisces renderer performance gain, %*
>>
>>     1   13,97   12,43   13,03   4,75%
>>     2   22,08   20,60   20,77   0,81%
>>     4   34,36   33,15   33,36   0,62%
>>     8   39,39   40,51   41,71   2,96%
>>     16  40,61   44,57   46,98   5,39%
>>     32  41,41   44,73   48,16   7,66%
>>     64  37,09   42,19   45,28   7,32%
>>
>>
>>     Well, first of all, congratulations to the JDK developers, don't
>>     know what changed in JDK 8, but
>>     GeoServer seems to like it quite a bit :-).
>>     That said, Laurent's patch also gives a visible boost, especially
>>     when several concurrent clients are
>>     asking for the maps.
>>
>>     Mind, as I said, this is no micro-benchmark, it is a real
>>     application loading doing a lot of I/O
>>     (from the operating system file cache), other processing before the
>>     data reaches the rendering
>>     pipeline, and then has to PNG encode the output BufferedImage (PNG
>>     encoding being rather
>>     expensive), so getting this speedup from just a change in the
>>     rendering pipeline is significant.
>>
>>     Long story short... personally I'd be very happy if this patch was
>>     going to be integrated in Java 8 :-)
>>
>>     Cheers
>>     Andrea
>>
>>     --
>>     ==
>>     GeoServer training in Milan, 6th & 7th June 2013!  Visit
>>     http://geoserver.geo-**solutions.it
>>     >
>> for more information.
>>
>>     ==
>>
>>     Ing. Andrea Aime
>>     @geowolf
>>     Technical Lead
>>
>>     GeoSolutions S.A.S.
>>     Via Poggio alle Viti 1187
>>     55054  Massarosa (LU)
>>     Italy
>>     phone: +39 0584 962313
>>     fax: +39 0584 1660272
>>     mob: +39  339 8844549
>>
>>     http://www.geo-solutions.it
>>     http://twitter.com/**geosolutions_it
>>
>>     ------------------------------**-------------------------
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From richard.bair at oracle.com  Wed Apr 17 20:26:11 2013
From: richard.bair at oracle.com (Richard Bair)
Date: Wed, 17 Apr 2013 13:26:11 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
	Memory enhancements
In-Reply-To: 
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
Message-ID: 

> 
> Also, this is with the Java version, right?  
> 
> Yes, my patch is pure java given as webrev:
>         http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/
>  
> We got a decent 2x speedup in FX by porting the version of Open Pisces that you started with to C code (all except on Linux where we couldn't find the right gcc options to make it faster than Hotspot).  So, we have yet to investigate a native version in the JDK which might provide even more gains?

Oleg did more analysis on this and it appears the reason hotspot on Linux was faster than the C version was because on Linux it is -server compiler (c2) whereas on Windows / Mac it is client compiler (c1). Possibly using -server on windows / mac would also have hotspot beating the C version, although that hasn't been tested.

Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From philip.race at oracle.com  Wed Apr 17 21:06:17 2013
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 Apr 2013 14:06:17 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: 
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
	
Message-ID: <516F0EC9.50706@oracle.com>

 > whereas on Windows / Mac it is client compiler (c1).

For Mac we only have a 64 bit VM which SFAIK should be c2 as well,
yet in that case native was presumably still faster. So its also a matter
of factoring in how good the code is that is generated by the C compiler.

-phil.

On 4/17/2013 1:26 PM, Richard Bair wrote:
>>
>>
>>     Also, this is with the Java version, right? 
>>
>>
>> Yes, my patch is pure java given as webrev:
>> http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ 
>> 
>>
>>     We got a decent 2x speedup in FX by porting the version of Open
>>     Pisces that you started with to C code (all except on Linux where
>>     we couldn't find the right gcc options to make it faster than
>>     Hotspot).  So, we have yet to investigate a native version in the
>>     JDK which might provide even more gains? 
>>
>
> Oleg did more analysis on this and it appears the reason hotspot on 
> Linux was faster than the C version was because on Linux it is -server 
> compiler (c2) whereas on Windows / Mac it is client compiler (c1). 
> Possibly using -server on windows / mac would also have hotspot 
> beating the C version, although that hasn't been tested.
>
> Richard
>



From linuxhippy at gmail.com  Wed Apr 17 21:15:53 2013
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 17 Apr 2013 23:15:53 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: 
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
Message-ID: 

Hi Laurent,

thanks for having some interest for my efforts !
> As I got almost no feedback, I felt quite disappointed and was thinking
> that improving pisces was not important ...
>

Glad to see work is ongoing to improve pisces's performance :)

I had a look at the patch just to be curious (I don't have reviewer
status), but to be honest I had troubles finding the relevant parts.
Having not followed the discussion that closely, it was almost impossible
for me to extract the real modifications from boilerplate/refactoring as
your patch weights almost 3000 modified lines.
I am just an intrested observer without any official state, yet personally
I would prefer smaller pieces with clear description/title.
However, I wouldn't want to cause you additional work and it's just a
single opinion.

Thanks for working on pisces!

Regards, Clemens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lana.steuck at oracle.com  Wed Apr 17 21:32:58 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 17 Apr 2013 21:32:58 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/corba: 2 new changesets
Message-ID: <20130417213302.D555C483CE@hg.openjdk.java.net>

Changeset: 9583a6431596
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/9583a6431596

Added tag jdk8-b84 for changeset 928f8b888deb

! .hgtags

Changeset: 44a8ce4a759f
Author:    katleman
Date:      2013-04-11 09:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/44a8ce4a759f

Added tag jdk8-b85 for changeset 9583a6431596

! .hgtags



From lana.steuck at oracle.com  Wed Apr 17 21:33:00 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 17 Apr 2013 21:33:00 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d: 21 new changesets
Message-ID: <20130417213302.8B087483CD@hg.openjdk.java.net>

Changeset: 15c1642967c9
Author:    andrew
Date:      2013-04-02 13:59 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/15c1642967c9

8009988: build-infra: Fix configure output for zip debuginfo check
Summary: No output from zip debuginfo option when default is used.
Reviewed-by: tbell

! common/autoconf/autogen.sh
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4

Changeset: f3cdfb3d360d
Author:    omajid
Date:      2013-04-02 14:13 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/f3cdfb3d360d

8011278: Allow using a system-installed giflib
Reviewed-by: andrew, prr

! common/autoconf/generated-configure.sh
! common/autoconf/libraries.m4

Changeset: 01f631f89fa3
Author:    katleman
Date:      2013-04-02 15:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/01f631f89fa3

Merge


Changeset: a0fa9e93efee
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/a0fa9e93efee

Added tag jdk8-b84 for changeset 01f631f89fa3

! .hgtags

Changeset: 52d1b385a4ed
Author:    erikj
Date:      2013-04-04 09:24 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/52d1b385a4ed

8006828: "SKIP_BOOT_CYCLE=false" must work in new building infrastructure
Reviewed-by: tbell, alanb

! common/autoconf/bootcycle-spec.gmk.in
! common/autoconf/spec.gmk.in
! common/makefiles/Jprt.gmk
! common/makefiles/Main.gmk

Changeset: 2d4156e077fa
Author:    erikj
Date:      2013-04-04 09:25 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/2d4156e077fa

8011372: Remove -p from cp in IdleCompilation.gmk
Reviewed-by: pliden, tbell

! common/makefiles/IdlCompilation.gmk

Changeset: 3b8ffb80db0f
Author:    erikj
Date:      2013-04-05 09:38 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/3b8ffb80db0f

8008373: JFR JTReg tests fail with CompilationError on MacOSX; missing '._sunec.jar'
Reviewed-by: tbell

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/MakeBase.gmk

Changeset: 653ff6bcf0b1
Author:    omajid
Date:      2013-04-08 14:07 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/653ff6bcf0b1

8011388: Support building zero and zeroshark with the new build
Reviewed-by: andrew, dholmes, erikj
Contributed-by: Omair Majid , Roman Kennke 

! common/autoconf/generated-configure.sh
! common/autoconf/hotspot-spec.gmk.in
! common/autoconf/jdk-options.m4
! common/autoconf/libraries.m4
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in

Changeset: 2f43964043c2
Author:    erikj
Date:      2013-04-09 09:42 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/2f43964043c2

8006288: build-infra: Use solaris nm and not gnm on solaris
Reviewed-by: tbell

! common/autoconf/compare.sh.in
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4

Changeset: 2ef28c12d649
Author:    erikj
Date:      2013-04-09 09:45 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/2ef28c12d649

8010465: Can't enable sjavac when building in jprt.
Reviewed-by: ohair, tbell

! common/makefiles/JavaCompilation.gmk
! common/makefiles/Jprt.gmk
! common/makefiles/MakeBase.gmk
! common/makefiles/MakeHelpers.gmk

Changeset: a09e9c9ca963
Author:    tbell
Date:      2013-04-09 13:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/a09e9c9ca963

8011348: use of which in common/autoconf/autogen.sh is not portable
Reviewed-by: erikj, katleman, mduigou

! common/autoconf/autogen.sh

Changeset: 7fc358f59436
Author:    katleman
Date:      2013-04-09 15:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/7fc358f59436

Merge


Changeset: 44bc9bc4da4d
Author:    katleman
Date:      2013-04-11 09:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/44bc9bc4da4d

Added tag jdk8-b85 for changeset 7fc358f59436

! .hgtags

Changeset: fc1e08c2bb27
Author:    mduigou
Date:      2013-04-01 11:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/fc1e08c2bb27

8010267: Add test-clean for cleaning of testoutput directory from output directory. Add depedency on test-clean to clean
Reviewed-by: mchung, tbell

! common/makefiles/Main.gmk

Changeset: 26a4456cb19e
Author:    jgish
Date:      2013-03-26 13:41 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/26a4456cb19e

8009824: webrev.ksh generated jdk.patch files do not handle renames, copies, and shouldn't be applied
Summary: use hg export --git to produce proper patch file
Reviewed-by: mduigou

! make/scripts/webrev.ksh

Changeset: 760074bec012
Author:    mduigou
Date:      2013-04-01 21:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/760074bec012

8011178: improve common/bin/hgforest.sh python detection (MacOS)
Reviewed-by: ohair

! common/bin/hgforest.sh

Changeset: bcbdbcfe7ed8
Author:    lana
Date:      2013-04-02 11:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/bcbdbcfe7ed8

Merge


Changeset: 7320922b694e
Author:    mduigou
Date:      2013-04-02 14:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/7320922b694e

8011342: hgforest.sh : 'python --version' not supported on older python
Reviewed-by: wetmore

! common/bin/hgforest.sh

Changeset: 575f2ca947ab
Author:    mduigou
Date:      2013-04-03 16:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/575f2ca947ab

8011350: hgforest.sh uses non-POSIX sh features that may fail with some shells
Reviewed-by: tbell, katleman, dholmes

! common/bin/hgforest.sh

Changeset: 11c057460b91
Author:    lana
Date:      2013-04-05 14:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/11c057460b91

Merge


Changeset: 4c13b7994f38
Author:    lana
Date:      2013-04-16 08:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/4c13b7994f38

Merge

! common/makefiles/Main.gmk



From lana.steuck at oracle.com  Wed Apr 17 21:33:05 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 17 Apr 2013 21:33:05 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jaxp: 2 new changesets
Message-ID: <20130417213316.D04D6483CF@hg.openjdk.java.net>

Changeset: 41b50e2c5ea3
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/41b50e2c5ea3

Added tag jdk8-b84 for changeset f5f40094ffcc

! .hgtags

Changeset: ca71ec37b2ef
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/ca71ec37b2ef

Added tag jdk8-b85 for changeset 41b50e2c5ea3

! .hgtags



From lana.steuck at oracle.com  Wed Apr 17 21:33:13 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 17 Apr 2013 21:33:13 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/nashorn: 31 new changesets
Message-ID: <20130417213340.EC2D1483D0@hg.openjdk.java.net>

Changeset: e0378f0a50da
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/e0378f0a50da

Added tag jdk8-b84 for changeset 999cc1bf5520

! .hgtags

Changeset: aed0529f5f5d
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/aed0529f5f5d

Added tag jdk8-b85 for changeset e0378f0a50da

! .hgtags

Changeset: 41a212ea8c0c
Author:    sundar
Date:      2013-03-28 20:48 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/41a212ea8c0c

8010924: Dealing with undefined property gets you a fatal stack
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
+ test/script/basic/JDK-8010924.js

Changeset: e2ea7a29b9c1
Author:    lagergren
Date:      2013-03-29 08:55 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/e2ea7a29b9c1

8010995: The bug ID 8010710 accidentally got two digits transposed in the checkin and unit test name
Reviewed-by: hannesw, sundar

+ test/script/basic/JDK-8010710.js
+ test/script/basic/JDK-8010710.js.EXPECTED
- test/script/basic/JDK-8017010.js
- test/script/basic/JDK-8017010.js.EXPECTED

Changeset: 704f3083af8a
Author:    sundar
Date:      2013-03-29 18:38 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/704f3083af8a

8011063: With older ant, we get the error "The  type doesn't support nested text data ("${run.te...jvmargs}")."
Reviewed-by: hannesw, ksrini

! make/build.xml

Changeset: a094fc010120
Author:    jlaskey
Date:      2013-03-31 08:19 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/a094fc010120

8011095: PropertyHashMap.rehash() does not grow enough
Reviewed-by: hannesw, lagergren
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/PropertyHashMap.java
! src/jdk/nashorn/internal/runtime/PropertyMap.java

Changeset: 3e4369fb810b
Author:    hannesw
Date:      2013-04-02 13:55 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/3e4369fb810b

8011219: Regression with recent PropertyMap history changes
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/runtime/PropertyMap.java

Changeset: 5362d96d5915
Author:    sundar
Date:      2013-04-02 17:40 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/5362d96d5915

8011209: Object.getOwnPropertyDescriptor(function(){"use strict"},"caller").get.length is not 0
Reviewed-by: lagergren, hannesw, jlaskey

! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
+ test/script/basic/JDK-8011209.js

Changeset: 9b845033c888
Author:    lana
Date:      2013-04-02 12:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/9b845033c888

Merge


Changeset: d82bc6ba3981
Author:    lana
Date:      2013-04-05 14:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/d82bc6ba3981

Merge


Changeset: af6fc67aa73d
Author:    jlaskey
Date:      2013-04-02 11:37 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/af6fc67aa73d

8011233: Create a Nashorn shell for JavaFX
Reviewed-by: lagergren, sundar
Contributed-by: james.laskey at oracle.com

! make/build.xml
! make/project.properties
+ tools/fxshell/jdk/nashorn/tools/FXShell.java

Changeset: be5d2e472e22
Author:    jlaskey
Date:      2013-04-02 11:38 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/be5d2e472e22

Merge


Changeset: 159dbe2e02eb
Author:    sundar
Date:      2013-04-02 20:42 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/159dbe2e02eb

8011237: Object.isExtensible(Object.getOwnPropertyDescriptor(function(){"use strict"},"caller").get) should be false
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
+ test/script/basic/JDK-8011237.js

Changeset: e9af5451d2d1
Author:    sundar
Date:      2013-04-02 23:01 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/e9af5451d2d1

8011274: Object.getOwnPropertyDescriptor(function(){"use strict"},"caller").get.hasOwnProperty("prototype") should be false
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
+ test/script/basic/JDK-8011274.js

Changeset: e63b20d4f08a
Author:    sundar
Date:      2013-04-03 11:41 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/e63b20d4f08a

8011357: Array.prototype.slice and Array.prototype.splice should not call user defined valueOf of start, end arguments more than once
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8011357.js

Changeset: 51da1afbab26
Author:    attila
Date:      2013-04-03 11:13 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/51da1afbab26

8011362: Overloaded method resolution foiled by nulls
Reviewed-by: hannesw, sundar

! src/jdk/internal/dynalink/beans/ClassString.java
! src/jdk/internal/dynalink/beans/OverloadedMethod.java
+ test/script/basic/JDK-8011362.js
+ test/script/basic/JDK-8011362.js.EXPECTED
+ test/src/jdk/nashorn/test/models/Jdk8011362TestSubject.java

Changeset: b4191da366be
Author:    sundar
Date:      2013-04-03 15:27 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/b4191da366be

8011365: Array.prototype.join and Array.prototype.toString do not throw TypeError on null, undefined
Reviewed-by: attila, hannesw, lagergren

! src/jdk/nashorn/internal/objects/NativeArray.java
! test/script/basic/JDK-8011362.js.EXPECTED
+ test/script/basic/JDK-8011365.js

Changeset: 4f7d7576e8c4
Author:    hannesw
Date:      2013-04-03 12:43 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/4f7d7576e8c4

8007774: Enable code cache again
Reviewed-by: lagergren, attila, sundar

! src/jdk/nashorn/internal/runtime/resources/Options.properties

Changeset: 82fed56d8dce
Author:    sundar
Date:      2013-04-03 20:17 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/82fed56d8dce

8011382: Data prototype methods and constructor do not call user defined toISOString, valueOf methods per spec.
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/NativeDate.java
+ test/script/basic/JDK-8011382.js

Changeset: a5a8ddc2e028
Author:    sundar
Date:      2013-04-04 10:24 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/a5a8ddc2e028

8011394: RegExp.prototype.test() does not call valueOf on lastIndex property as per the spec.
Reviewed-by: lagergren, jlaskey, hannesw

! src/jdk/nashorn/internal/objects/NativeRegExp.java
+ test/script/basic/JDK-8011394.js

Changeset: 0548c134b9ac
Author:    sundar
Date:      2013-04-04 13:54 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/0548c134b9ac

8011421: When using Object.defineProperty on arrays, PropertyDescriptor's property accessors are invoked multiple times
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8011421.js

Changeset: f638f2f094f7
Author:    jlaskey
Date:      2013-04-04 09:05 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/f638f2f094f7

8011540: PropertyMap histories should not begin with empty map
Reviewed-by: lagergren, sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/PropertyMap.java

Changeset: 069923cc9de5
Author:    jlaskey
Date:      2013-04-04 09:06 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/069923cc9de5

Merge


Changeset: 18df6640e63f
Author:    sundar
Date:      2013-04-04 18:30 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/18df6640e63f

8011543: "".split(undefined,{valueOf:function(){throw 2}}) does not throw exception
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/NativeString.java
+ test/script/basic/JDK-8011543.js

Changeset: 5eb1427b6a6d
Author:    attila
Date:      2013-04-04 15:53 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/5eb1427b6a6d

8011544: Allow subclassing Java classes from script without creating instances
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/objects/NativeJava.java
+ src/jdk/nashorn/internal/runtime/linker/AdaptationException.java
+ src/jdk/nashorn/internal/runtime/linker/AdaptationResult.java
+ src/jdk/nashorn/internal/runtime/linker/ClassAndLoader.java
+ src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
+ src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
+ src/jdk/nashorn/internal/runtime/linker/JavaAdapterGeneratorBase.java
+ src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java
! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! src/jdk/nashorn/internal/runtime/resources/Messages.properties
+ test/script/basic/javaclassoverrides.js
+ test/script/basic/javaclassoverrides.js.EXPECTED

Changeset: 73e1270b240c
Author:    attila
Date:      2013-04-04 15:55 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/73e1270b240c

Merge


Changeset: 349360cc1df5
Author:    sundar
Date:      2013-04-04 20:46 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/349360cc1df5

8011552: Arrays with missing elements are not properly sorted
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8011552.js

Changeset: 050fd5696bcb
Author:    attila
Date:      2013-04-04 18:32 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/050fd5696bcb

8011555: Invalid class name in with block with JavaImporter causes MH type mismatch
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/runtime/WithObject.java
+ test/script/basic/JDK-8011555.js
+ test/script/basic/JDK-8011555.js.EXPECTED

Changeset: 1c29dc809de2
Author:    hannesw
Date:      2013-04-05 19:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/1c29dc809de2

8009230: Nashorn rejects extended RegExp syntax accepted by all major JS engines
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8009230.js
+ test/script/basic/JDK-8009230.js.EXPECTED

Changeset: 437861485ffa
Author:    jlaskey
Date:      2013-04-09 08:36 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/437861485ffa

Merge


Changeset: 35881a9d0fc2
Author:    lana
Date:      2013-04-16 08:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/35881a9d0fc2

Merge

- test/script/basic/JDK-8017010.js
- test/script/basic/JDK-8017010.js.EXPECTED



From lana.steuck at oracle.com  Wed Apr 17 21:33:13 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 17 Apr 2013 21:33:13 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/langtools: 20 new changesets
Message-ID: <20130417213420.0604F483D2@hg.openjdk.java.net>

Changeset: 4a48f3173534
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/4a48f3173534

Added tag jdk8-b84 for changeset cfb65ca92082

! .hgtags

Changeset: 2c9acb17f41a
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/2c9acb17f41a

Added tag jdk8-b85 for changeset 4a48f3173534

! .hgtags

Changeset: 330b35b27e68
Author:    darcy
Date:      2013-03-26 17:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/330b35b27e68

7041251: Use j.u.Objects utility methods in langtools
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/Pair.java
! src/share/classes/javax/annotation/processing/AbstractProcessor.java

Changeset: 33b6a52f0037
Author:    darcy
Date:      2013-03-26 18:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/33b6a52f0037

7059170: Assume availablility of URLClassLoader.close
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java
- src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java

Changeset: 7bebe17ff323
Author:    mcimadamore
Date:      2013-03-28 11:38 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/7bebe17ff323

8010469: Bad assertion in LambdaToMethod
Summary: Add assertion in LambdaToMethod.serializedLambdaName
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java

Changeset: a200d8ccfe47
Author:    mcimadamore
Date:      2013-03-28 11:39 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/a200d8ccfe47

8010490: FindBugs: double assignments in LambdaToMethod.visitIdent
Summary: Remove dead code from LambdaToMethod
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java

Changeset: 991f11e13598
Author:    jjg
Date:      2013-03-28 10:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/991f11e13598

8006346: doclint should make allowance for headers generated by standard doclet
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/doclint/Env.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
+ test/tools/javac/doclint/ImplicitHeadersTest.java
+ test/tools/javadoc/doclint/ImplicitHeadersTest.java

Changeset: d3648557391b
Author:    jjg
Date:      2013-03-28 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/d3648557391b

8010511: Tests are creating files in /tmp
Reviewed-by: darcy

! test/tools/javac/T6558476.java
! test/tools/javac/T6900149.java
! test/tools/javac/diags/CheckExamples.java
! test/tools/javac/diags/RunExamples.java

Changeset: 29c6984a1673
Author:    vromero
Date:      2013-04-02 10:51 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/29c6984a1673

4965689: class literal code wastes a byte
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/Items.java
+ test/tools/javac/T4965689/ClassLiteralWastesByteTest.java

Changeset: 46d2f144ebbd
Author:    lana
Date:      2013-04-02 12:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/46d2f144ebbd

Merge


Changeset: 0d47e6131490
Author:    darcy
Date:      2013-04-03 12:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/0d47e6131490

8011052: Add DEFAULT to javax.lang.model.Modifier
Reviewed-by: abuckley, jjg

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/javax/lang/model/element/Modifier.java
! test/tools/javac/processing/model/element/TestExecutableElement.java

Changeset: e06dc8345d9c
Author:    lana
Date:      2013-04-05 14:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/e06dc8345d9c

Merge


Changeset: b71a61d39cf7
Author:    mcimadamore
Date:      2013-04-08 15:51 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/b71a61d39cf7

8010922: Cleanup: add support for ad-hoc method check logic
Summary: Support pluggable method checkers
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java

Changeset: b54122b9372d
Author:    mcimadamore
Date:      2013-04-08 15:52 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/b54122b9372d

8010823: DefaultMethodTest.testReflectCall fails with new lambda VM
Summary: Fix lambda test
Reviewed-by: jjg

! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java

Changeset: e9d986381414
Author:    mcimadamore
Date:      2013-04-08 15:53 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/e9d986381414

8010404: Lambda debugging: redundant LineNumberTable entry for lambda capture
Summary: Ignore indy entries in LineNumberTable
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! test/tools/javac/lambda/TestInvokeDynamic.java

Changeset: 94a202228ec2
Author:    mcimadamore
Date:      2013-04-08 15:57 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/94a202228ec2

8009131: Overload: javac should discard methods that lead to errors in lambdas with implicit parameter types
Summary: Lambdas that have errors in their bodies should make enclosing overload resolution fail
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/BadArgTypesInLambda.java
! test/tools/javac/lambda/BadRecovery.out
! test/tools/javac/lambda/TargetType01.java
- test/tools/javac/lambda/TargetType01.out
! test/tools/javac/lambda/TargetType43.out
+ test/tools/javac/lambda/TargetType66.java
+ test/tools/javac/lambda/TargetType66.out

Changeset: c635a966ce84
Author:    mcimadamore
Date:      2013-04-08 15:59 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/c635a966ce84

8010822: Intersection type cast for functional expressions does not follow spec EDR
Summary: Remove support for marker interfaces; redefine intersection type casts to be order-independent
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
+ test/tools/javac/diags/examples/NotAnInterfaceComponent.java
- test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java
! test/tools/javac/lambda/Intersection01.java
- test/tools/javac/lambda/Intersection01.out
! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java

Changeset: b402b93cbe38
Author:    jjg
Date:      2013-04-08 11:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/b402b93cbe38

8011676: Instances of Tokens.Comment should not be defined in inner classes
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java

Changeset: 3f3cc8d3f13c
Author:    jjg
Date:      2013-04-08 11:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/3f3cc8d3f13c

8011677: EndPosTables should avoid hidden references to Parser
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java

Changeset: 1f19b84efa6d
Author:    lana
Date:      2013-04-16 08:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/1f19b84efa6d

Merge

- src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java
- test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java
- test/tools/javac/lambda/Intersection01.out
- test/tools/javac/lambda/TargetType01.out



From lana.steuck at oracle.com  Wed Apr 17 21:33:53 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 17 Apr 2013 21:33:53 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/hotspot: 81 new changesets
Message-ID: <20130417213647.DD7B8483D3@hg.openjdk.java.net>

Changeset: ac242ddfa319
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/ac242ddfa319

Added tag jdk8-b84 for changeset af788b85010e

! .hgtags

Changeset: d26674db4d91
Author:    amurillo
Date:      2013-03-28 19:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/d26674db4d91

8011022: new hotspot build - hs25-b26
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 0c3ee6f1fa23
Author:    coleenp
Date:      2013-03-27 08:19 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/0c3ee6f1fa23

8009531: Crash when redefining class with annotated method
Summary: Neglected to copy the annotations in clone_with_new_data when they were moved to ConstMethod.
Reviewed-by: acorn, sspitsyn, dcubed

! src/share/vm/oops/constMethod.cpp
! src/share/vm/oops/constMethod.hpp
! src/share/vm/oops/method.cpp

Changeset: aa758f0c5b1c
Author:    hseigel
Date:      2013-03-27 11:41 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/aa758f0c5b1c

8010833: Test7116786.java is failing on most configs after fix for 8010667
Summary: Update test to recognize that non-zero pad bytes for lookupswitch/tablewsitch opcodes are now valid.
Reviewed-by: dcubed, twisti, kvn, coleenp, dholmes

! test/runtime/7116786/Test7116786.java

Changeset: b601102d00c8
Author:    hseigel
Date:      2013-03-27 13:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b601102d00c8

Merge


Changeset: cd3089a56438
Author:    acorn
Date:      2013-03-27 14:10 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/cd3089a56438

8009731: Confusing error message for loader constraint violation
Summary: Fix text, overwritten type and holder for resolved method
Reviewed-by: coleenp, dcubed, minqi, dholmes

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/klassVtable.cpp

Changeset: 53f4040e809c
Author:    acorn
Date:      2013-03-27 16:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/53f4040e809c

Merge


Changeset: b5bae74160b7
Author:    zgu
Date:      2013-03-27 15:41 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b5bae74160b7

8010474: [parfait] Undefined return value of the functions in hotspot/src/share/vm/services/memTracker.hpp
Summary: Fixed functions that miss return values
Reviewed-by: coleenp, acorn, kvn

! src/share/vm/services/memTracker.hpp

Changeset: 26e0c03da92c
Author:    zgu
Date:      2013-03-27 13:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/26e0c03da92c

Merge

- make/windows/projectfiles/kernel/Makefile
- make/windows/projectfiles/kernel/vm.def
- make/windows/projectfiles/kernel/vm.dsw

Changeset: f044c45bee68
Author:    zgu
Date:      2013-03-27 22:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/f044c45bee68

Merge


Changeset: 1b90c7607451
Author:    minqi
Date:      2013-03-27 17:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/1b90c7607451

2178143: JVM crashes if the number of bound CPUs changed during runtime
Summary: Supply a new flag -XX:+AssumeMP to workaround the problem. With the flag is turned on, assume VM run on MP platform so is_MP() will return true that sync calls will not skip away.
Reviewed-by: dholmes, acorn, dcubed, jmasa
Contributed-by: yumin.qi at oracle.com

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp

Changeset: d7adf726b18a
Author:    minqi
Date:      2013-03-28 00:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/d7adf726b18a

Merge


Changeset: c0f9217203b2
Author:    dcubed
Date:      2013-03-29 08:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/c0f9217203b2

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: d886ac1dfd36
Author:    coleenp
Date:      2013-03-31 21:43 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/d886ac1dfd36

8010723: fatal error: acquiring lock Metaspace allocation lock/5 out of order
Summary: Avoid holding SystemDictionary_lock while calling Klass::remove_unshareable_info
Reviewed-by: coleenp, acorn
Contributed-by: ioi.lam at oracle.com

! src/share/vm/classfile/systemDictionary.cpp

Changeset: e458120c6e1a
Author:    sla
Date:      2013-03-28 15:39 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e458120c6e1a

8002118: WindbgDebuggerLocal should not try to load 64-bit debug libraries for 32-bit JVM
Reviewed-by: sspitsyn, zgu
Contributed-by: peter.allwin at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java

Changeset: ede380e13960
Author:    mgerdin
Date:      2013-04-02 11:28 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/ede380e13960

8009763: Add WB test for String.intern()
Summary: Add convenience method in StringTable, add WhiteBox method and simple sanity test
Reviewed-by: mgerdin, zgu
Contributed-by: leonid.mesnik at oracle.com

! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/prims/whitebox.cpp
+ test/runtime/interned/SanityTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 8c03fc47511d
Author:    iklam
Date:      2013-04-01 14:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/8c03fc47511d

8011048: Possible reading from unmapped memory in UTF8::as_quoted_ascii()
Summary: Pass utf_length parameter to UTF8::as_quoted_ascii()
Reviewed-by: dcubed, minqi

! src/share/vm/oops/symbol.cpp
! src/share/vm/utilities/utf8.cpp
! src/share/vm/utilities/utf8.hpp

Changeset: a4e8dac9db8c
Author:    zgu
Date:      2013-04-02 07:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a4e8dac9db8c

Merge


Changeset: 2e093b564241
Author:    mgerdin
Date:      2013-03-28 10:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/2e093b564241

7014552: gc/lock/jni/jnilockXXX works too slow on 1-processor machine
Summary: Keep a counter of how many times we were stalled by the GC locker, add a diagnostic flag which sets the limit.
Reviewed-by: brutisso, ehelin, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 754c24457b20
Author:    tschatzl
Date:      2013-03-27 19:21 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/754c24457b20

7112912: Message "Error occurred during initialization of VM" on boxes with lots of RAM
Summary: Ergonomics now also takes available virtual memory into account when deciding for a heap size. The helper method to determine the maximum allocatable memory block now uses the appropriate OS specific calls to retrieve available virtual memory for the java process. In 32 bit environments this method now also searches for the maximum actually reservable amount of memory. Merge previously separate implementations for Linux/BSD/Solaris into a single method.
Reviewed-by: jmasa, tamao

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/posix/vm/os_posix.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp

Changeset: 24ef5fb05e0f
Author:    johnc
Date:      2013-03-29 13:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/24ef5fb05e0f

8010463: G1: Crashes with -UseTLAB and heap verification
Summary: Some parts of the G1 heap can only be walked during a safepoint. Skip verifying these parts of the heap when verifying during JVM startup.
Reviewed-by: brutisso, tschatzl

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/thread.cpp
+ test/gc/TestVerifyBeforeGCDuringStartup.java

Changeset: 8bf6338972ce
Author:    ehelin
Date:      2013-03-23 09:16 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/8bf6338972ce

8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1"
Reviewed-by: brutisso, sla, ctornqvi

! test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java
+ test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java

Changeset: cc5b5976d72c
Author:    tschatzl
Date:      2013-04-02 10:03 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/cc5b5976d72c

8005857: assert in GC_locker from PSOldGen::expand with -XX:+PrintGCDetails and Verbose
Summary: Use GC_locker::is_active_and_needs_gc() instead of GC_locker::is_active() for providing information about the reason of heap expansion.
Reviewed-by: jmasa, johnc

! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp

Changeset: 15c04fe93c18
Author:    mgerdin
Date:      2013-04-03 09:19 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/15c04fe93c18

Merge

- make/windows/projectfiles/kernel/Makefile
- make/windows/projectfiles/kernel/vm.def
- make/windows/projectfiles/kernel/vm.dsw
! src/os/linux/vm/os_linux.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
- test/runtime/8007736/TestStaticIF.java

Changeset: 0c039865ef2b
Author:    mgerdin
Date:      2013-04-04 19:07 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/0c039865ef2b

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp

Changeset: 46f6f063b272
Author:    roland
Date:      2013-03-21 09:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/46f6f063b272

7153771: array bound check elimination for c1
Summary: when possible optimize out array bound checks, inserting predicates when needed.
Reviewed-by: never, kvn, twisti
Contributed-by: thomaswue 

! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_LinearScan_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Canonicalizer.hpp
! src/share/vm/c1/c1_CodeStubs.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_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_InstructionPrinter.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_Optimizer.cpp
+ src/share/vm/c1/c1_RangeCheckElimination.cpp
+ src/share/vm/c1/c1_RangeCheckElimination.hpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/c1/c1_Runtime1.hpp
! src/share/vm/c1/c1_ValueMap.cpp
! src/share/vm/c1/c1_ValueMap.hpp
! src/share/vm/c1/c1_globals.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/runtime/globals.hpp

Changeset: a57fc14f798a
Author:    roland
Date:      2013-03-21 22:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a57fc14f798a

Merge


Changeset: e370f63dc5b1
Author:    bharadwaj
Date:      2013-03-22 07:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e370f63dc5b1

8009539: JVM crash when run lambda testng tests
Summary: Ensure class pointer is non-null before dereferencing it to check if it is loaded.
Reviewed-by: kvn

! src/share/vm/opto/parse2.cpp

Changeset: 360ce06580b8
Author:    bharadwaj
Date:      2013-03-22 13:35 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/360ce06580b8

Merge


Changeset: 3c786355ffb4
Author:    morris
Date:      2013-03-23 06:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3c786355ffb4

8009026: [parfait] Null pointer deference in hotspot/src/share/vm/code/nmethod.cpp
Summary: add guarantee() to nmethod constructor and checks to ensure CodeCache has space before allocation
Reviewed-by: kvn

! src/share/vm/code/codeCache.hpp
! src/share/vm/code/nmethod.cpp

Changeset: 818a1ac7da7a
Author:    morris
Date:      2013-03-24 12:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/818a1ac7da7a

Merge


Changeset: 16885e702c88
Author:    twisti
Date:      2013-03-25 17:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/16885e702c88

7198429: need checked categorization of caller-sensitive methods in the JDK
Reviewed-by: kvn, jrose

! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vframe.hpp

Changeset: b808febcad9a
Author:    neliasso
Date:      2013-03-26 10:05 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b808febcad9a

8010281: Remove code that is never executed
Reviewed-by: kvn, roland
Contributed-by: niclas.adlertz at oracle.com

! src/share/vm/opto/ifg.cpp

Changeset: 30f42e691e70
Author:    kvn
Date:      2013-03-26 12:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/30f42e691e70

8004640: C2 assert failure in memnode.cpp: NULL+offs not RAW address
Summary: always transform AddP nodes in IdealKit by calling _gvn.transform().
Reviewed-by: roland, twisti

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/phaseX.cpp

Changeset: d595e8ddadd9
Author:    roland
Date:      2013-03-29 17:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/d595e8ddadd9

8010934: assert failure in c1_LinearScan.cpp: "asumption: non-Constant instructions have only virtual operands"
Summary: incorrect code to skip some ArrayLength instructions in LIRGenerator
Reviewed-by: kvn

! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_RangeCheckElimination.cpp

Changeset: cd9ad42dfde0
Author:    bharadwaj
Date:      2013-03-29 20:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/cd9ad42dfde0

Merge

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 6b19fe41b577
Author:    kmo
Date:      2013-03-30 08:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/6b19fe41b577

8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros
Summary: Improve EC_TRACE and RC_TRACE* to use the do-while(0) trick for statement-like macro
Reviewed-by: sspitsyn, dcubed

! src/share/vm/prims/jvmtiEventController.cpp
! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp

Changeset: 53028d751155
Author:    neliasso
Date:      2013-04-02 09:30 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/53028d751155

7034299: Faulty winsock initialization code
Reviewed-by: dholmes, sla, ctornqvi

! src/os/windows/vm/os_windows.cpp

Changeset: e961c11b85fe
Author:    kvn
Date:      2013-04-03 11:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e961c11b85fe

8011102: Clear AVX registers after return from JNI call
Summary: Execute vzeroupper instruction after JNI call and on exits in jit compiled code which use 256bit vectors.
Reviewed-by: roland

! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
! src/os_cpu/linux_x86/vm/linux_x86_64.ad
! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
! src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 0a8c2ea3902d
Author:    rasbold
Date:      2013-04-03 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/0a8c2ea3902d

8010437: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset
Summary: Fix shorten_branches() to accurately count an initial nop that may be inserted in a block that starts with a safepoint.
Reviewed-by: kvn

! src/share/vm/opto/output.cpp

Changeset: 70c52efb2cbd
Author:    neliasso
Date:      2013-04-04 09:18 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/70c52efb2cbd

8006008: Memory leak in hotspot/src/share/vm/adlc/archDesc.cpp
Reviewed-by: roland, kvn
Contributed-by: niclas.adlertz at oracle.com

! src/share/vm/adlc/archDesc.cpp

Changeset: 6c4abd4a9595
Author:    roland
Date:      2013-04-04 09:33 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/6c4abd4a9595

8010399: Test8009761.java "Failed: init recursive calls: 5498. After deopt 5494".
Summary: test from 8009761 shouldn't be run with -Xcomp
Reviewed-by: kvn

! test/compiler/8009761/Test8009761.java

Changeset: 9125a548c1eb
Author:    roland
Date:      2013-04-04 02:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/9125a548c1eb

Merge


Changeset: 573cf206e381
Author:    neliasso
Date:      2013-04-04 09:30 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/573cf206e381

8006014: Memory leak in hotspot/src/share/vm/adlc/dfa.cpp
Reviewed-by: kvn, roland
Contributed-by: niclas.adlertz at oracle.com

! src/share/vm/adlc/dfa.cpp

Changeset: bab5cbf74b5f
Author:    kvn
Date:      2013-04-04 12:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/bab5cbf74b5f

8011198: LP64 setting is not preserved on Solaris after 8006965
Summary: Fixed incremental build makefiles generated by buildtree.make. Consolidated unix build.sh.
Reviewed-by: twisti

- make/bsd/build.sh
! make/bsd/makefiles/buildtree.make
+ make/build.sh
- make/linux/build.sh
! make/linux/makefiles/buildtree.make
- make/solaris/build.sh
! make/solaris/makefiles/buildtree.make
! src/os/posix/launcher/launcher.script

Changeset: 0ca3dd0ffaba
Author:    bharadwaj
Date:      2013-04-04 17:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/0ca3dd0ffaba

Merge

- make/bsd/build.sh
- make/linux/build.sh
- make/solaris/build.sh
! src/os/windows/vm/os_windows.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/runtime/globals.hpp

Changeset: a947f40fb536
Author:    amurillo
Date:      2013-04-04 21:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/a947f40fb536

Merge

- make/bsd/build.sh
- make/linux/build.sh
- make/solaris/build.sh

Changeset: 42fe530cd478
Author:    amurillo
Date:      2013-04-04 21:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/42fe530cd478

Added tag hs25-b26 for changeset a947f40fb536

! .hgtags

Changeset: 5dcfeb396fed
Author:    katleman
Date:      2013-04-11 09:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/5dcfeb396fed

Added tag jdk8-b85 for changeset 42fe530cd478

! .hgtags

Changeset: dcdeb150988c
Author:    amurillo
Date:      2013-04-04 21:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/dcdeb150988c

8011584: new hotspot build - hs25-b27
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 3b890cd4da64
Author:    ctornqvi
Date:      2013-04-03 21:41 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3b890cd4da64

8009125: Add NMT tests for Virtual Memory operations
Summary: Tests added for Reserve/Commit/Uncommit/Unreserve operations
Reviewed-by: zgu, mgerdin

! src/share/vm/prims/whitebox.cpp
- test/runtime/NMT/AllocTestType.java
+ test/runtime/NMT/MallocTestType.java
+ test/runtime/NMT/ThreadedMallocTestType.java
+ test/runtime/NMT/ThreadedVirtualAllocTestType.java
+ test/runtime/NMT/VirtualAllocTestType.java
! test/testlibrary/OutputAnalyzerTest.java
! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 8554c55669b0
Author:    hseigel
Date:      2013-04-04 08:47 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/8554c55669b0

8010943: guarantee(length == 0) failed: invalid method ordering length
Summary: Add DumpSharedSpaces to IF condition to handle verify during -Xshare:dump.
Reviewed-by: coleenp, zgu

! src/share/vm/oops/instanceKlass.cpp

Changeset: bad3bed4b323
Author:    ccheung
Date:      2013-03-29 14:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/bad3bed4b323

8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c
Summary: a simple fix to add FileList_free(fl) before returning NULL.
Reviewed-by: zgu, coleenp, minqi

! src/share/tools/launcher/wildcard.c

Changeset: 17bf4d428955
Author:    ccheung
Date:      2013-04-03 16:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/17bf4d428955

8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp
Reviewed-by: zgu, iklam

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp

Changeset: cc32ccaaf47f
Author:    mikael
Date:      2013-04-04 10:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/cc32ccaaf47f

8003310: Enable -Wunused-function when compiling with gcc
Summary: Add the -Wunused-function flag and remove a number of unused functions.
Reviewed-by: dholmes, coleenp, kvn

! make/linux/makefiles/gcc.make
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/x86_64.ad
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/compiler/compileLog.cpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/ptrQueue.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/memory/heap.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jniCheck.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/synchronizer.hpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/globalDefinitions.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 4c8bb5e4f68f
Author:    zgu
Date:      2013-04-05 12:19 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/4c8bb5e4f68f

8011161: NMT: Memory leak when encountering out of memory error while initializing memory snapshot
Summary: Fix memory leaks when NMT fails to initialize snapshot and worker thread
Reviewed-by: dcubed, ccheung, rdurbin

! src/share/vm/services/memTracker.cpp

Changeset: 8be1318fbe77
Author:    dcubed
Date:      2013-04-05 10:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/8be1318fbe77

Merge

! src/cpu/x86/vm/x86_64.ad
! src/os/bsd/vm/os_bsd.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/c1/c1_LIRGenerator.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/runtime/arguments.cpp
- test/runtime/NMT/AllocTestType.java

Changeset: 46d24f112c27
Author:    dcubed
Date:      2013-04-05 16:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/46d24f112c27

Merge

- make/bsd/build.sh
- make/linux/build.sh
- make/solaris/build.sh

Changeset: 4b7cf00ccb08
Author:    ccheung
Date:      2013-04-05 11:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/4b7cf00ccb08

8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp
Reviewed-by: zgu, coleenp, hseigel, dholmes

! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/os/windows/vm/perfMemory_windows.cpp

Changeset: b933e75e7cbe
Author:    zgu
Date:      2013-04-05 23:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b933e75e7cbe

Merge


Changeset: 09b0d3e9ba6c
Author:    bharadwaj
Date:      2013-04-09 08:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/09b0d3e9ba6c

8011671: JCK tests on static interface methods fail under b84: Illegal type at constant pool entry 5
Summary: Restore incorrect removal of support for static interface method verification in Java 8
Reviewed-by: kvn, coleenp

! src/share/vm/classfile/verifier.cpp

Changeset: 9b4a6a172a8a
Author:    amurillo
Date:      2013-04-11 01:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/9b4a6a172a8a

Added tag hs25-b27 for changeset 09b0d3e9ba6c

! .hgtags

Changeset: 511e334ee345
Author:    amurillo
Date:      2013-04-11 16:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/511e334ee345

Merge

! .hgtags
- test/runtime/NMT/AllocTestType.java

Changeset: e437668ced9d
Author:    amurillo
Date:      2013-04-11 01:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/e437668ced9d

8011948: new hotspot build - hs25-b28
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 68fe50d4f1d5
Author:    johnc
Date:      2013-04-05 10:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/68fe50d4f1d5

8011343: Add new flag for verifying the heap during startup
Summary: Perform verification during VM startup under control of new flag and within a VMOperation.
Reviewed-by: stefank, jmasa, brutisso

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp
- test/gc/TestVerifyBeforeGCDuringStartup.java
+ test/gc/TestVerifyDuringStartup.java

Changeset: 8617e38bb4cb
Author:    jmasa
Date:      2013-02-11 10:31 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/8617e38bb4cb

8008508: CMS does not correctly reduce heap size after a Full GC
Reviewed-by: johnc, ysr

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.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/vmStructs.cpp

Changeset: 83f27710f5f7
Author:    brutisso
Date:      2013-04-08 07:49 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/83f27710f5f7

7197666: java -d64 -version core dumps in a box with lots of memory
Summary: Allow task queues to be mmapped instead of malloced on Solaris
Reviewed-by: coleenp, jmasa, johnc, tschatzl

! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/taskqueue.hpp

Changeset: 63f57a8c5283
Author:    mgerdin
Date:      2013-04-09 15:32 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/63f57a8c5283

8009808: TEST-BUG : test case is using bash style tests. Default shell for jtreg is bourne. thus failure
Summary: Rewrite test to use Java only instead of shell script
Reviewed-by: mgerdin, brutisso
Contributed-by: leonid.mesnik at oracle.com

+ test/gc/6941923/Test6941923.java
- test/gc/6941923/test6941923.sh

Changeset: ba42fd5e00e6
Author:    mgerdin
Date:      2013-04-10 13:27 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/ba42fd5e00e6

8010196: NPG: Internal Error: Metaspace allocation lock -- possible deadlock
Summary: Refactor the CLD dependency list into a separate class. Use an ObjectLocker to synchronize additions to the CLD dependency list.
Reviewed-by: stefank, coleenp

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
+ test/gc/metaspace/G1AddMetaspaceDependency.java

Changeset: 7b835924c31c
Author:    stefank
Date:      2013-04-10 14:26 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/7b835924c31c

8011872: Include Bit Map addresses in the hs_err files
Reviewed-by: brutisso, jmasa

! 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/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/utilities/bitMap.cpp
! src/share/vm/utilities/bitMap.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 480d934f62a8
Author:    mgerdin
Date:      2013-04-11 16:35 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/480d934f62a8

Merge

! src/share/vm/runtime/arguments.cpp
- test/runtime/NMT/AllocTestType.java

Changeset: 705ef39fcaa9
Author:    neliasso
Date:      2013-04-05 11:09 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/705ef39fcaa9

8006016: Memory leak at hotspot/src/share/vm/adlc/output_c.cpp
Reviewed-by: kvn, roland
Contributed-by: niclas.adlertz at oracle.com

! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp

Changeset: f67065f02409
Author:    bharadwaj
Date:      2013-04-08 07:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/f67065f02409

8010913: compiler/6863420 often exceeds timeout
Summary: add longer timeout for jtreg, add internal timeout thread to prevent spurious timeouts
Reviewed-by: twisti, kvn
Contributed-by: drchase 

! test/compiler/6863420/Test.java

Changeset: b84fd7d73702
Author:    iignatyev
Date:      2013-04-09 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b84fd7d73702

8007288: Additional WB API for compiler's testing
Reviewed-by: kvn, vlivanov

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/compilationPolicy.hpp
! src/share/vm/utilities/accessFlags.hpp
! src/share/vm/utilities/globalDefinitions.hpp
+ test/compiler/whitebox/ClearMethodStateTest.java
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
+ test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
+ test/compiler/whitebox/SetForceInlineMethodTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 84ab5667f290
Author:    roland
Date:      2013-04-10 09:52 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/84ab5667f290

8011706: specjvm2008 test xml.transform gets array bound exception with c1
Summary: loop invariant code motion may move load before store to the same field
Reviewed-by: kvn

! src/share/vm/c1/c1_ValueMap.cpp
+ test/compiler/8011706/Test8011706.java

Changeset: d79859ff6535
Author:    kmo
Date:      2013-04-11 07:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/d79859ff6535

8011952: Missing ResourceMarks in TraceMethodHandles
Summary: add missing ResourceMark under TraceMethodHandles in LinkResolver
Reviewed-by: dholmes

! src/share/vm/interpreter/linkResolver.cpp

Changeset: 9befe2fce567
Author:    vlivanov
Date:      2013-04-11 09:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/9befe2fce567

8011972: Field can be erroneously marked as contended when @Contended annotation isn't present
Reviewed-by: kvn, kmo, shade

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp

Changeset: b5db9d29062f
Author:    vlivanov
Date:      2013-04-11 11:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b5db9d29062f

Merge


Changeset: 7a5aec879506
Author:    bharadwaj
Date:      2013-04-11 17:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/7a5aec879506

Merge

! src/share/vm/prims/whitebox.cpp
! src/share/vm/utilities/globalDefinitions.hpp
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 6d88a566d369
Author:    amurillo
Date:      2013-04-11 21:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/6d88a566d369

Merge

- test/gc/6941923/test6941923.sh
- test/gc/TestVerifyBeforeGCDuringStartup.java

Changeset: 5201379fe487
Author:    amurillo
Date:      2013-04-11 21:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/5201379fe487

Added tag hs25-b28 for changeset 6d88a566d369

! .hgtags



From lana.steuck at oracle.com  Wed Apr 17 21:35:06 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 17 Apr 2013 21:35:06 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 53 new changesets
Message-ID: <20130417214549.C1ABC483D4@hg.openjdk.java.net>

Changeset: b68094f8263f
Author:    erikj
Date:      2013-03-28 09:36 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b68094f8263f

8010908: Images target failes when configured with --disable-zip-debug-info
Reviewed-by: tbell

! makefiles/Images.gmk

Changeset: 9c76ea43d491
Author:    omajid
Date:      2013-04-02 14:13 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9c76ea43d491

8011278: Allow using a system-installed giflib
Reviewed-by: andrew, prr

! makefiles/CompileNativeLibraries.gmk
! src/share/native/sun/awt/splashscreen/splashscreen_gif.c

Changeset: 7b4721e4edb4
Author:    katleman
Date:      2013-04-02 15:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7b4721e4edb4

Merge

! makefiles/CompileNativeLibraries.gmk

Changeset: 43da85020921
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/43da85020921

Added tag jdk8-b84 for changeset 7b4721e4edb4

! .hgtags

Changeset: e22961ea91bd
Author:    erikj
Date:      2013-04-05 09:39 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e22961ea91bd

8008373: JFR JTReg tests fail with CompilationError on MacOSX; missing '._sunec.jar'
Reviewed-by: tbell

! makefiles/CompileDemos.gmk
! makefiles/CompileJavaClasses.gmk
! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyFiles.gmk
! makefiles/CopyIntoClasses.gmk
! makefiles/CopySamples.gmk
! makefiles/GendataFontConfig.gmk
! makefiles/GensrcCharacterData.gmk
! makefiles/GensrcMisc.gmk
! makefiles/GensrcSwing.gmk
! makefiles/SignJars.gmk
! makefiles/Tools.gmk

Changeset: fddd158b872a
Author:    omajid
Date:      2013-04-08 14:09 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/fddd158b872a

8011388: Support building zero and zeroshark with the new build
Reviewed-by: andrew, dholmes, erikj
Contributed-by: Omair Majid , Roman Kennke 

! makefiles/Profiles.gmk

Changeset: 296676d534c5
Author:    katleman
Date:      2013-04-09 15:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/296676d534c5

Merge


Changeset: 081327aac5be
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/081327aac5be

Added tag jdk8-b85 for changeset 296676d534c5

! .hgtags

Changeset: 2904672aed21
Author:    lana
Date:      2013-04-09 14:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/2904672aed21

Merge


Changeset: 96750ebc769b
Author:    denis
Date:      2013-03-27 16:19 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/96750ebc769b

7075105: WIN: Provide a way to format HTML on drop
Reviewed-by: uta, serb

! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
! src/share/classes/java/awt/datatransfer/DataFlavor.java
! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
! src/share/classes/sun/awt/datatransfer/DataTransferer.java
! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java
! src/solaris/classes/sun/awt/X11/XDataTransferer.java
! src/windows/classes/sun/awt/windows/WDataTransferer.java
+ test/java/awt/datatransfer/HTMLDataFlavors/HTMLDataFlavorTest.java
+ test/java/awt/datatransfer/HTMLDataFlavors/HtmlTransferable.java
+ test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.html
+ test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.java
+ test/java/awt/datatransfer/HTMLDataFlavors/PutAllHtmlFlavorsOnClipboard.java
+ test/java/awt/datatransfer/HTMLDataFlavors/PutOnlyAllHtmlFlavorOnClipboard.java
+ test/java/awt/datatransfer/HTMLDataFlavors/PutSelectionAndFragmentHtmlFlavorsOnClipboard.java

Changeset: 29570523b6cb
Author:    ant
Date:      2013-03-29 16:12 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/29570523b6cb

8010375: sun.swing.JLightweightFrame should be implemented for XToolkit
Reviewed-by: anthony

! src/share/classes/sun/swing/JLightweightFrame.java
! src/solaris/classes/sun/awt/X11/XFramePeer.java
+ src/solaris/classes/sun/awt/X11/XLightweightFramePeer.java
! src/solaris/classes/sun/awt/X11/XToolkit.java

Changeset: c23d58901aa6
Author:    lana
Date:      2013-04-02 16:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c23d58901aa6

Merge

- make/com/sun/servicetag/Makefile
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh

Changeset: 36cb7921bc98
Author:    mcherkas
Date:      2013-04-03 20:42 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/36cb7921bc98

8011123: serialVersionUID of java.awt.dnd.InvalidDnDOperationException changed in JDK8-b82
Reviewed-by: anthony, serb

! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java

Changeset: 35da3878deef
Author:    mcherkas
Date:      2013-04-03 20:54 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/35da3878deef

8010925: COPY AND PASTE TO AND FROM SIGNED APPLET FAILS AFTER FIRST INTERNAL COPY PRFRMD
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/macosx/CClipboard.java
! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
! src/macosx/native/sun/awt/CClipboard.m

Changeset: 2c36899500a0
Author:    pchelko
Date:      2013-04-05 18:29 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/2c36899500a0

8006941: [macosx] Deadlock in drag and drop
7199783: Setting cursor on DragSourceContext does not work on OSX
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java
! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java
! src/macosx/classes/sun/lwawt/macosx/CDropTarget.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/CDragSource.h
! src/macosx/native/sun/awt/CDragSource.m
! src/macosx/native/sun/awt/CDragSourceContextPeer.m
! src/macosx/native/sun/awt/CDropTarget.m
! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java
+ test/java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java

Changeset: 0b083b0e8e63
Author:    kshefov
Date:      2013-04-08 17:18 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0b083b0e8e63

7153702: [TEST_BUG] [macosx] Synchronization problem in test javax/swing/JPopupMenu/6827786/bug6827786.java
Reviewed-by: serb, alexsch

! test/javax/swing/JPopupMenu/6827786/bug6827786.java

Changeset: 981142561d1b
Author:    lana
Date:      2013-04-09 15:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/981142561d1b

Merge


Changeset: 3b56ef8e1ce1
Author:    martin
Date:      2013-03-26 13:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3b56ef8e1ce1

8007905: To add a system property to create zip file without using ZIP64 end table when entry count > 64k
Summary: Provide a system property to inhibit ZIP64 mode for >64k entries
Reviewed-by: alanb, sherman

! src/share/classes/java/util/zip/ZipOutputStream.java
+ test/java/util/zip/EntryCount64k.java

Changeset: 266b43683a2c
Author:    martin
Date:      2013-03-26 13:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/266b43683a2c

8010316: Improve handling of char sequences containing surrogates
Summary: Fix and optimize codePointAt, codePointBefore and similar methods
Reviewed-by: sherman, okutsu, ulfzibis, kizune

! src/share/classes/java/lang/AbstractStringBuilder.java
! src/share/classes/java/lang/Character.java
! test/java/lang/StringBuilder/Supplementary.java

Changeset: caafe6dca35d
Author:    ehelin
Date:      2013-03-21 20:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/caafe6dca35d

8009427: Re-enable tests that were disable to ease complicated push
Reviewed-by: sla, mchung, dcubed
Contributed-by: Erik Helin 

! test/ProblemList.txt

Changeset: 49602f599c08
Author:    dxu
Date:      2013-03-27 09:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/49602f599c08

8010837: FileInputStream.available() throw IOException when encountering negative available values
Summary: Remove the check in the native code to allow negative values
Reviewed-by: mchung

! src/solaris/native/java/io/io_util_md.c
+ test/java/io/FileInputStream/NegativeAvailable.java

Changeset: ae03282ba501
Author:    darcy
Date:      2013-03-27 09:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ae03282ba501

7185456: (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotations
Reviewed-by: mduigou, jfranck

! src/share/classes/sun/reflect/annotation/AnnotationType.java

Changeset: d254a5f9b93f
Author:    acorn
Date:      2013-03-27 13:40 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d254a5f9b93f

8010846: Update the corresponding test in test/vm/verifier/TestStaticIF.java
Summary: Remove test flag -XX:-UseSplitVerifier, not supported classfile 52
Reviewed-by: acorn, hseigel

! test/vm/verifier/TestStaticIF.java

Changeset: 811c771acf65
Author:    sundar
Date:      2013-03-28 14:36 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/811c771acf65

8010991: Enable test/javax/script/GetInterfaceTest.java again
Reviewed-by: lagergren, hannesw

! test/javax/script/GetInterfaceTest.java

Changeset: a87fac00915e
Author:    weijun
Date:      2013-03-28 20:27 +0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a87fac00915e

8010125: keytool -importkeystore could create a pkcs12 keystore with different storepass and keypass
Reviewed-by: vinnie

! src/share/classes/sun/security/tools/keytool/Main.java
! src/share/classes/sun/security/tools/keytool/Resources.java
+ test/sun/security/tools/keytool/p12importks.sh

Changeset: e433ed08b733
Author:    mchung
Date:      2013-03-28 13:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e433ed08b733

8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level
Reviewed-by: mchung
Contributed-by: peter.levart at gmail.com, bourges.laurent at gmail.com

! src/share/classes/sun/util/logging/PlatformLogger.java
! test/sun/util/logging/PlatformLoggerTest.java

Changeset: b590bd37a6d0
Author:    mduigou
Date:      2013-04-01 12:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b590bd37a6d0

8010268: Remove dependence upon clean target from jdk/test/Makefile prep target
Reviewed-by: tbell, mchung

! test/Makefile

Changeset: 0cccdb9a9a4c
Author:    mduigou
Date:      2013-04-01 20:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0cccdb9a9a4c

7143928: Optimize empty HashMap and ArrayList
Reviewed-by: mduigou
Contributed-by: Sergey Linetskiy , John Rose , Mike Duigou 

! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashMap.java
+ test/java/util/Map/BasicSerialization.java

Changeset: 5ee837ba093a
Author:    mduigou
Date:      2013-04-01 20:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5ee837ba093a

8011187: Remove obsolete/unused targets from jdk/test/Makefile
Reviewed-by: ohair

! test/Makefile

Changeset: de228734b742
Author:    mduigou
Date:      2013-04-01 20:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/de228734b742

8011199: Backout changeset JDK-7143928 (0cccdb9a9a4c)
Reviewed-by: darcy, dholmes

! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashMap.java
- test/java/util/Map/BasicSerialization.java

Changeset: f1b89d4cce82
Author:    sla
Date:      2013-04-02 10:32 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f1b89d4cce82

8009558: linked_md.c::dll_build_name can get stuck in an infinite loop
Reviewed-by: alanb, sspitsyn

! src/share/back/export/sys.h
! src/share/back/transport.c
! src/share/demo/jvmti/hprof/hprof_md.h
! src/solaris/back/linker_md.c
! src/solaris/demo/jvmti/hprof/hprof_md.c
! src/windows/back/linker_md.c
! src/windows/demo/jvmti/hprof/hprof_md.c

Changeset: e6c3b8e74e50
Author:    sherman
Date:      2013-04-02 10:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e6c3b8e74e50

8007379: Base64.getMimeDecoder().decode() throws IAE for a non-base64 character after padding
8008925: Base64.getMimeDecoder().decode() does not ignore padding chars
Summary: updated implementation and spec for corner cases.
Reviewed-by: alanb

! src/share/classes/java/util/Base64.java
! test/java/util/Base64/TestBase64.java

Changeset: 7fbae9125437
Author:    lana
Date:      2013-04-02 11:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7fbae9125437

Merge


Changeset: b4f68aca1000
Author:    darcy
Date:      2013-04-02 16:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b4f68aca1000

8004979: java.lang.reflect.Modifier.toString should include "default"
Reviewed-by: mduigou

! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/Modifier.java
! test/java/lang/reflect/Method/GenericStringTest.java

Changeset: c534937f6e94
Author:    alanb
Date:      2013-04-03 13:15 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c534937f6e94

8011234: Performance regression with ftp protocol when uploading in image mode
Reviewed-by: chegar

! src/share/classes/sun/net/ftp/impl/FtpClient.java

Changeset: eb8f7bc6f964
Author:    alanb
Date:      2013-04-03 13:41 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/eb8f7bc6f964

8011373: Property java.runtime.profile should be removed (left-over code)
Reviewed-by: lancea, dholmes

! src/share/classes/sun/misc/Version.java.template

Changeset: 27ae4f9c7826
Author:    lancea
Date:      2013-04-03 12:47 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/27ae4f9c7826

8011393: Typo in javadoc for SerialClob.truncate
Reviewed-by: darcy

! src/share/classes/javax/sql/rowset/serial/SerialClob.java

Changeset: 9a6ef3391f32
Author:    naoto
Date:      2013-04-03 10:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9a6ef3391f32

7091601: Arabic Locale: can not set type of digit in application level
Reviewed-by: okutsu

! src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java

Changeset: 7b1189bf1d7b
Author:    dxu
Date:      2013-04-04 15:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7b1189bf1d7b

8000406: change files using @GenerateNativeHeader to use @Native
Summary: Use @Native annotation to mark constants interested by native codes
Reviewed-by: alanb, anthony, prr

! src/macosx/classes/apple/laf/JRSUIConstants.java
! src/macosx/classes/com/apple/eawt/FullScreenHandler.java
! src/macosx/classes/com/apple/eawt/event/GestureHandler.java
! src/macosx/classes/sun/java2d/OSXSurfaceData.java
! src/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
! src/macosx/native/jobjc/src/core/PrimitiveCoder.hs
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java
! src/macosx/native/jobjc/src/core/native/Invoke.m
! src/macosx/native/jobjc/src/core/native/JObjCRuntime.m
! src/macosx/native/sun/awt/PrinterView.m
! src/share/classes/java/awt/Adjustable.java
! src/share/classes/java/awt/AlphaComposite.java
! src/share/classes/java/awt/BasicStroke.java
! src/share/classes/java/awt/Choice.java
! src/share/classes/java/awt/DisplayMode.java
! src/share/classes/java/awt/Image.java
! src/share/classes/java/awt/List.java
! src/share/classes/java/awt/PopupMenu.java
! src/share/classes/java/awt/SystemColor.java
! src/share/classes/java/awt/TextComponent.java
! src/share/classes/java/awt/Transparency.java
! src/share/classes/java/awt/color/ColorSpace.java
! src/share/classes/java/awt/color/ICC_Profile.java
! src/share/classes/java/awt/datatransfer/StringSelection.java
! src/share/classes/java/awt/dnd/DnDConstants.java
! src/share/classes/java/awt/event/ActionEvent.java
! src/share/classes/java/awt/event/AdjustmentEvent.java
! src/share/classes/java/awt/event/ComponentEvent.java
! src/share/classes/java/awt/event/FocusEvent.java
! src/share/classes/java/awt/event/InputMethodEvent.java
! src/share/classes/java/awt/event/MouseWheelEvent.java
! src/share/classes/java/awt/event/WindowEvent.java
! src/share/classes/java/awt/geom/PathIterator.java
! src/share/classes/java/awt/image/AffineTransformOp.java
! src/share/classes/java/awt/image/ConvolveOp.java
! src/share/classes/java/awt/image/DataBuffer.java
! src/share/classes/java/awt/image/ImageConsumer.java
! src/share/classes/java/awt/image/ImageObserver.java
! src/share/classes/java/awt/peer/ComponentPeer.java
! src/share/classes/java/awt/print/PageFormat.java
! src/share/classes/java/awt/print/Pageable.java
! src/share/classes/java/awt/print/Printable.java
! src/share/classes/sun/awt/EmbeddedFrame.java
! src/share/classes/sun/awt/SunHints.java
! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java
! src/share/classes/sun/awt/image/BufImgSurfaceData.java
! src/share/classes/sun/font/FontManager.java
! src/share/classes/sun/java2d/SunGraphics2D.java
! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java
! src/share/classes/sun/java2d/opengl/OGLContext.java
! src/share/classes/sun/java2d/pipe/BufferedContext.java
! src/share/classes/sun/java2d/pipe/BufferedOpCodes.java
! src/share/classes/sun/java2d/pipe/BufferedPaints.java
! src/share/classes/sun/java2d/pipe/BufferedTextPipe.java
! src/share/classes/sun/java2d/pipe/RenderBuffer.java
! src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java
! src/share/classes/sun/java2d/pipe/hw/AccelSurface.java
! src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java
! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java
! src/share/classes/sun/security/pkcs11/Secmod.java
! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/nio/ch/sctp/AssociationChange.java
! src/solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java
! src/solaris/classes/sun/nio/ch/sctp/ResultContainer.java
! src/solaris/native/sun/awt/awt_InputMethod.c
! src/solaris/native/sun/awt/fontpath.c
! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java
! src/windows/classes/sun/java2d/d3d/D3DContext.java
! src/windows/classes/sun/java2d/d3d/D3DPaints.java
! src/windows/native/sun/java2d/d3d/D3DContext.h
! src/windows/native/sun/windows/awt_Component.h
! src/windows/native/sun/windows/awt_DnDDS.cpp
! src/windows/native/sun/windows/awt_Frame.cpp
! src/windows/native/sun/windows/awt_List.h
! src/windows/native/sun/windows/awt_PopupMenu.cpp
! src/windows/native/sun/windows/awt_PopupMenu.h
! src/windows/native/sun/windows/awt_TextComponent.h
! src/windows/native/sun/windows/awt_Toolkit.cpp

Changeset: 7d4e30730f80
Author:    valeriep
Date:      2013-04-04 20:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7d4e30730f80

7155720: PKCS11 minor issues in native code
Summary: Added OOM handling to address the two issues found by parfait.
Reviewed-by: weijun

! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c

Changeset: b62a76763bf3
Author:    mchung
Date:      2013-04-05 10:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b62a76763bf3

8011380: FX dependency on PlatformLogger broken by 8010309
Reviewed-by: alanb

! src/share/classes/java/util/logging/LoggingProxyImpl.java
! src/share/classes/sun/util/logging/LoggingProxy.java
! src/share/classes/sun/util/logging/LoggingSupport.java
! src/share/classes/sun/util/logging/PlatformLogger.java
! test/sun/util/logging/PlatformLoggerTest.java

Changeset: b702977e7212
Author:    khazra
Date:      2013-04-05 12:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b702977e7212

5001942: Missings SOCKS support for direct connections
Summary: Add support for socksNonProxyHosts
Reviewed-by: chegar, khazra
Contributed-by: Christos Zoulas 

! src/share/classes/sun/net/spi/DefaultProxySelector.java
! test/java/net/Socks/SocksProxyVersion.java

Changeset: ba231ac2890a
Author:    lana
Date:      2013-04-05 14:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ba231ac2890a

Merge


Changeset: 785f3a04ee05
Author:    dxu
Date:      2013-04-05 17:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/785f3a04ee05

8011602: jobjc build failure on Mac
Summary: Remove @Native annotation from macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java
Reviewed-by: mchung, dholmes

! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java
! src/share/classes/sun/java2d/opengl/OGLContext.java

Changeset: 16f63a94c231
Author:    darcy
Date:      2013-04-05 18:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/16f63a94c231

8011590: More tests for core reflection modeling of default methods
Reviewed-by: mduigou

+ test/java/lang/reflect/Method/DefaultMethodModeling.java

Changeset: 04617e462512
Author:    lancea
Date:      2013-04-08 15:29 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/04617e462512

8006036: (process) cleanup code in java/lang/Runtime/exec/WinCommand.java
Reviewed-by: lancea
Contributed-by: Jim Gish 

! test/java/lang/Runtime/exec/WinCommand.java

Changeset: 3db793b080d8
Author:    martin
Date:      2013-04-08 16:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3db793b080d8

8010849: (str) Optimize StringBuilder.append(null)
Summary: Append 4 chars instead of the string "null"
Reviewed-by: mduigou, forax, jgish

! src/share/classes/java/lang/AbstractStringBuilder.java

Changeset: 3e5a18c3e599
Author:    darcy
Date:      2013-04-08 17:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3e5a18c3e599

6298888: Add toGenericString to j.l.Class and getTypeName to j.l.reflect.Type
6992705: Include modifiers in Class.toGenericString()
Summary: Class.toGenericString and supporting changes; additional reviews by Peter Levart
Reviewed-by: alanb

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/Modifier.java
! src/share/classes/java/lang/reflect/Parameter.java
! src/share/classes/java/lang/reflect/Type.java
+ test/java/lang/Class/GenericStringTest.java

Changeset: 57e9eaeca323
Author:    alanb
Date:      2013-04-09 15:51 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/57e9eaeca323

8010393: Update JAX-WS RI to 2.2.9-b12941
Reviewed-by: mullan

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 50bc8e085a09
Author:    chegar
Date:      2013-04-09 17:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/50bc8e085a09

8005696: Add CompletableFuture
Reviewed-by: chegar, martin

! make/java/java/FILES_java.gmk
+ src/share/classes/java/util/concurrent/CompletableFuture.java
+ src/share/classes/java/util/concurrent/CompletionException.java
+ test/java/util/concurrent/CompletableFuture/Basic.java

Changeset: f304311cfe9f
Author:    lana
Date:      2013-04-09 15:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f304311cfe9f

Merge

! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java

Changeset: 6e3763e737b0
Author:    lana
Date:      2013-04-16 08:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6e3763e737b0

Merge


Changeset: 271d5bf7d61f
Author:    lana
Date:      2013-04-17 12:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/271d5bf7d61f

Merge

! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyIntoClasses.gmk



From bourges.laurent at gmail.com  Thu Apr 18 04:52:54 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 18 Apr 2013 06:52:54 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: 
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
	
Message-ID: 

Hi clemens

Le 17 avr. 2013 23:16, "Clemens Eisserer"  a ?crit :
>
> Hi Laurent,
>
>> thanks for having some interest for my efforts !
>> As I got almost no feedback, I felt quite disappointed and was thinking
that improving pisces was not important ...
>
>
> Glad to see work is ongoing to improve pisces's performance :)
>

Thanks a lot: I am working on pisces during my spare time and
congratulations is very important for my motivation.

> I had a look at the patch just to be curious (I don't have reviewer
status), but to be honest I had troubles finding the relevant parts.

I agree I modify the code to help me understanding it : @override, grouped
fields, constant first, debug logs ...

I can revert most of these boilerplates ... during cleanup.

I sent the patch as webrev to let other people evaluate its performance
using their own platform, work load, benchmarks ...

> Having not followed the discussion that closely, it was almost impossible
for me to extract the real modifications from boilerplate/refactoring as
your patch weights almost 3000 modified lines.

I looked at the webrev and I advocate I can discard many line changes.
As I use netbeans, it modified the code so easily... nevermind.

> I am just an intrested observer without any official state, yet
personally I would prefer smaller pieces with clear description/title.
> However, I wouldn't want to cause you additional work and it's just a
single opinion.
>

Ok. I mainly modified memory handling: use a renderer cache to reuse arrays
and pisces class instances to avoid too much allocations and resizing ...
stored in thread local or concurrent queue.

> Thanks for working on pisces!

Thanks for your feedback too.

Laurent

>
> Regards, Clemens
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Sergey.Bylokhov at oracle.com  Thu Apr 18 13:24:52 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 18 Apr 2013 17:24:52 +0400
Subject: [OpenJDK 2D-Dev] [8] Request for review: 8004859
 Graphics.getClipBounds/getClip return difference nonequivalent bounds,
 depending from transform.
In-Reply-To: <50F74C49.9000800@oracle.com>
References: <50C9B74A.7050806@oracle.com> <50CA3D30.5020104@oracle.com>
	<50CCB2CA.8030307@oracle.com> <50D29862.2060806@oracle.com>
	<50D2DF22.7020007@oracle.com> <50D2E484.3030004@oracle.com>
	<50D35065.1080307@oracle.com> <50D38628.2050807@oracle.com>
	<50D39EA4.6050802@oracle.com> <50D3A0B1.2040407@oracle.com>
	<50D3A530.4070604@oracle.com> <50D3B083.800@oracle.com>
	<50D3B45F.4010903@oracle.com> <50D3C3D5.7080506@oracle.com>
	<50D4464F.8050401@oracle.com> <50E4DA79.7020703@oracle.com>
	<50F46025.7080705@oracle.com> <50F74C49.9000800@oracle.com>
Message-ID: <516FF424.4010900@oracle.com>

Hello Jim.

On 1/17/13 4:56 AM, Jim Graham wrote:
> The original code in getClipBounds would end up returning a "new 
> Rectangle()" if the clip was an empty rectangle due to the way that 
> "Rectangle2D/Path2D.getBounds()" works.  You now use 
> setFrame(getBounds2D()) which will attempt to preserve the dimensions 
> of empty clips.  So, the "preserve the size of an empty clip" support 
> is new.
>
> I then mentioned that we don't need to go out of our way to preserve 
> the dimensions of an empty clip, but you seem to be saying that we 
> don't want to change this behavior - but your new code represents the 
> break with existing behaviors, no?
I returned to this problem and studied it a little more deeply.
Description.
Assume we set clip=Rectangle[100, 100,-100,-100] for sg2d with a 
different transform.
  1 identity/translate (default mode for non-retina): getClip () will 
return Rectangle[100, 100,-100,-100].
  2 scale (default mode for retina): getClip() will return 
Rectangle[0,0,100,100] <- bug and it should be fixed.
  3 generic: getClip will return Rectangle[0,0,0,0], because we convert 
Rectangle to the Shape through RectIterator, which ignores the negative 
width and height. Note that x and y were not preserved only if w and 
h<0, but if w = h =0, then x and y will be preserved.

In an original fix I made case 2 like case 1, so from the point of view 
of users there was no difference in case of retina display.
But now I have doubts and I think that all cases shall work equally like 
in case 3.
What do you think?

>
>             ...jim


-- 
Best regards, Sergey.



From patrick at reini.net  Thu Apr 18 18:18:29 2013
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 18 Apr 2013 20:18:29 +0200
Subject: [OpenJDK 2D-Dev] Fix proposal for UnixPrintServiceLookup not
	returning consistent values
In-Reply-To: <1366229461.2858.4.camel@wsccuw01.ccuw.ch>
References: <921DCFDE-B4B9-4E51-A95E-6439111A7AC4@reini.net>
	<1366229461.2858.4.camel@wsccuw01.ccuw.ch>
Message-ID: 

Hi James,

I'm new on this list and would like to submit a fix. Unfortunately I did not received the bug number for my submitted problem, where I think I got a fix for.

Could you help me on this?

Cheers

Patrick 

Am 17.04.2013 um 22:11 schrieb Patrick Reinhart :

> On Tue, 2013-04-16 at 14:15 +0200, Patrick Reinhart wrote:
> 
> Here's the link to suggested fix:
> 
> http://reinharts.dyndns.org/webrev/
> 
> Cheers Patrick


From jennifer.godinez at oracle.com  Thu Apr 18 21:21:11 2013
From: jennifer.godinez at oracle.com (Jennifer Godinez)
Date: Thu, 18 Apr 2013 14:21:11 -0700
Subject: [OpenJDK 2D-Dev] [8] Review request for 8007642: Media Names on
 Java Print Do Not Match the Printer's and Confuse Users
In-Reply-To: <516ED29B.6040503@oracle.com>
References: <51152343.8060303@oracle.com> <512634FC.8060504@oracle.com>
	<513D98BD.8030201@oracle.com> <5155EAE1.8090208@oracle.com>
	<516E9B34.7080200@oracle.com> <516ED29B.6040503@oracle.com>
Message-ID: <517063C7.3070601@oracle.com>

Hi Anton,

I got a crash when I tried to go down the list of Media Size in Page 
Setup Dialog.  Output is below.  Can you confirm?

Jennifer

OUTPUT:
---------------------------
PrintService = Win32 Printer : PrimoPDF
*********************
AWT Assertion Failure
*********************
value != NULL
File 'Hashtable.cpp', at line 124
GetLastError() is 0 : The operation completed successfully.

Do you want to break into the debugger?
*********************
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (os_windows_x86.cpp:143), pid=8932, tid=9484
#  guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: Unexpected 
result f
rom topLevelExceptionFilter
#


On 4/17/2013 9:49 AM, Jennifer Godinez wrote:
> Thanks Anton.  I will test your fix and let you know.
>
> Jennifer
>
> On 4/17/2013 5:53 AM, Anton Litvinov wrote:
>> Hello Jennifer,
>>
>> Thank you very much for the review of this fix. For reproduction of 
>> this bug and testing of the fix the printer "PrimoPDF" with its 
>> driver "PrimoPDF" was used. This printer is a virtual printer which 
>> generates PDF files as a result of printing jobs and which can be 
>> downloaded at the URL (http://www.primopdf.com). Such a printer was 
>> selected for testing, because it supports the paper size "11 x 17" in 
>> inches, with which the bug was experienced by a user according to the 
>> bug report.
>>
>> Also I was able to observe a similar situation with the printers: 
>> "Microsoft XPS Document Writer", "Xerox WorkCentre 4250 GPD PS" but 
>> on paper sizes different from "11 x 17". For example, if the printer 
>> "Xerox WorkCentre 4250 GPD PS" is used, JDK interprets the paper size 
>> "Postcard (100 x 148 mm)" as "Postcard (JIS)" and, when algorithm of 
>> the method "sun.print.Win32PrintService.getMediaSizes" encounters the 
>> paper size "Japanese Postcard", it interprets it as "Postcard (JIS)" 
>> again, which leaves just one media size "Postcard (JIS)" from 2 in 
>> Java cross-platform Page Setup and Print dialogs. I think that this 
>> situation is similar to the case with "11 x 17" paper size, because 
>> some user can also be willing to see exactly "Postcard (100 x 148 
>> mm)" media size in the mentioned Java dialogs, where it will be 
>> absent, whoever this fix still will not allow "Postcard (100 x 148 
>> mm)" to be displayed.
>>
>> Thank you,
>> Anton
>>
>> On 3/29/2013 11:26 PM, Jennifer Godinez wrote:
>>> Hi Anton,
>>>
>>> What printer and printer driver version did you use to test your fix?
>>> Thanks.
>>>
>>> Jennifer
>>>
>>> On 3/11/2013 1:41 AM, Anton Litvinov wrote:
>>>> Hello,
>>>>
>>>> Please review the following fix. This is the second reminder 
>>>> message. Please take into account that the original review request 
>>>> was sent more than 1 month ago and no response has been received yet.
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>>>
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 2/21/2013 6:53 PM, Anton Litvinov wrote:
>>>>> Hello,
>>>>>
>>>>> I am sorry for inconvenience. This is a reminder message. I am 
>>>>> still interested in reception of the response to this review 
>>>>> request and just want to be sure that it is not lost on the mail 
>>>>> alias's archive.
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>>
>>>>> On 2/8/2013 8:09 PM, Anton Litvinov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the following fix for a bug.
>>>>>>
>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>>>>>
>>>>>> The bug consists in the fact that Java cross-platform Page Setup 
>>>>>> and Print dialogs do not always list all media sizes supported by 
>>>>>> a printer. The fix is based on addition of dynamic creation of 
>>>>>> new media names of the type "sun.print.Win32MediaSize" based on 
>>>>>> paper names received from Windows API function with corresponding 
>>>>>> media sizes of the type 
>>>>>> "javax.print.attribute.standard.MediaSize" for the case, when the 
>>>>>> printer's media size name, which is being analyzed in 
>>>>>> "sun.print.Win32PrintService.initMedia" method, is not added to 
>>>>>> the final list of media sizes supported by the printer because of 
>>>>>> an already existing duplicate in that list. In such a case the 
>>>>>> printer's paper size matches with one of the media sizes 
>>>>>> registered in JDK, while the paper size ID does not match with 
>>>>>> any ID known to JDK.
>>>>>>
>>>>>> Also the code in "Win32PrintService.findWin32Media" method was 
>>>>>> altered to allow three cases from "switch" block to work as 
>>>>>> expected, because currently they never match with "dmIndex" 
>>>>>> value, since it is always less then 
>>>>>> "dmPaperToPrintService.length" under "if" statement.
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>
>>>>
>>>
>>
>



From anton.litvinov at oracle.com  Fri Apr 19 16:23:10 2013
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Fri, 19 Apr 2013 20:23:10 +0400
Subject: [OpenJDK 2D-Dev] [8] Review request for 8007642: Media Names on
 Java Print Do Not Match the Printer's and Confuse Users
In-Reply-To: <517063C7.3070601@oracle.com>
References: <51152343.8060303@oracle.com> <512634FC.8060504@oracle.com>
	<513D98BD.8030201@oracle.com> <5155EAE1.8090208@oracle.com>
	<516E9B34.7080200@oracle.com> <516ED29B.6040503@oracle.com>
	<517063C7.3070601@oracle.com>
Message-ID: <51716F6E.3090105@oracle.com>

Hello Jennifer,

I am sorry, but I cannot confirm existence of such a crash, because in 
my local environment I do not experience any unchecked Java exceptions 
and JVM crashes. Today I have made a fresh clone of all workspaces from 
the repository (http://hg.openjdk.java.net/jdk8/jdk8), have applied this 
fix and have compiled the JDK 8. Also, to be on the safe side, PrimoPDF 
printer has been reinstalled with the latest version available for 
downloading from the web site mentioned in my previous e-mail. And I was 
not able to reproduce your crash neither by scrolling the Media Sizes in 
Page Setup Dialog, nor by moving in that list using the keyboard.

Did you get this crash with the latest source code of the whole JDK 8 
patched with the fix? Do you use the test application provided on the 
bug's record page? Perhaps, you are using a "fastdebug" build of JDK 8, 
if it is so, then can this kind of build be considered as a reliable for 
verification of fixes?

Thank you,
Anton

On 4/19/2013 1:21 AM, Jennifer Godinez wrote:
> Hi Anton,
>
> I got a crash when I tried to go down the list of Media Size in Page 
> Setup Dialog.  Output is below.  Can you confirm?
>
> Jennifer
>
> OUTPUT:
> ---------------------------
> PrintService = Win32 Printer : PrimoPDF
> *********************
> AWT Assertion Failure
> *********************
> value != NULL
> File 'Hashtable.cpp', at line 124
> GetLastError() is 0 : The operation completed successfully.
>
> Do you want to break into the debugger?
> *********************
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (os_windows_x86.cpp:143), pid=8932, tid=9484
> #  guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: 
> Unexpected result f
> rom topLevelExceptionFilter
> #
>
>
> On 4/17/2013 9:49 AM, Jennifer Godinez wrote:
>> Thanks Anton.  I will test your fix and let you know.
>>
>> Jennifer
>>
>> On 4/17/2013 5:53 AM, Anton Litvinov wrote:
>>> Hello Jennifer,
>>>
>>> Thank you very much for the review of this fix. For reproduction of 
>>> this bug and testing of the fix the printer "PrimoPDF" with its 
>>> driver "PrimoPDF" was used. This printer is a virtual printer which 
>>> generates PDF files as a result of printing jobs and which can be 
>>> downloaded at the URL (http://www.primopdf.com). Such a printer was 
>>> selected for testing, because it supports the paper size "11 x 17" 
>>> in inches, with which the bug was experienced by a user according to 
>>> the bug report.
>>>
>>> Also I was able to observe a similar situation with the printers: 
>>> "Microsoft XPS Document Writer", "Xerox WorkCentre 4250 GPD PS" but 
>>> on paper sizes different from "11 x 17". For example, if the printer 
>>> "Xerox WorkCentre 4250 GPD PS" is used, JDK interprets the paper 
>>> size "Postcard (100 x 148 mm)" as "Postcard (JIS)" and, when 
>>> algorithm of the method "sun.print.Win32PrintService.getMediaSizes" 
>>> encounters the paper size "Japanese Postcard", it interprets it as 
>>> "Postcard (JIS)" again, which leaves just one media size "Postcard 
>>> (JIS)" from 2 in Java cross-platform Page Setup and Print dialogs. I 
>>> think that this situation is similar to the case with "11 x 17" 
>>> paper size, because some user can also be willing to see exactly 
>>> "Postcard (100 x 148 mm)" media size in the mentioned Java dialogs, 
>>> where it will be absent, whoever this fix still will not allow 
>>> "Postcard (100 x 148 mm)" to be displayed.
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 3/29/2013 11:26 PM, Jennifer Godinez wrote:
>>>> Hi Anton,
>>>>
>>>> What printer and printer driver version did you use to test your fix?
>>>> Thanks.
>>>>
>>>> Jennifer
>>>>
>>>> On 3/11/2013 1:41 AM, Anton Litvinov wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following fix. This is the second reminder 
>>>>> message. Please take into account that the original review request 
>>>>> was sent more than 1 month ago and no response has been received yet.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>>
>>>>> On 2/21/2013 6:53 PM, Anton Litvinov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I am sorry for inconvenience. This is a reminder message. I am 
>>>>>> still interested in reception of the response to this review 
>>>>>> request and just want to be sure that it is not lost on the mail 
>>>>>> alias's archive.
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>>
>>>>>> On 2/8/2013 8:09 PM, Anton Litvinov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the following fix for a bug.
>>>>>>>
>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>>>>>>
>>>>>>> The bug consists in the fact that Java cross-platform Page Setup 
>>>>>>> and Print dialogs do not always list all media sizes supported 
>>>>>>> by a printer. The fix is based on addition of dynamic creation 
>>>>>>> of new media names of the type "sun.print.Win32MediaSize" based 
>>>>>>> on paper names received from Windows API function with 
>>>>>>> corresponding media sizes of the type 
>>>>>>> "javax.print.attribute.standard.MediaSize" for the case, when 
>>>>>>> the printer's media size name, which is being analyzed in 
>>>>>>> "sun.print.Win32PrintService.initMedia" method, is not added to 
>>>>>>> the final list of media sizes supported by the printer because 
>>>>>>> of an already existing duplicate in that list. In such a case 
>>>>>>> the printer's paper size matches with one of the media sizes 
>>>>>>> registered in JDK, while the paper size ID does not match with 
>>>>>>> any ID known to JDK.
>>>>>>>
>>>>>>> Also the code in "Win32PrintService.findWin32Media" method was 
>>>>>>> altered to allow three cases from "switch" block to work as 
>>>>>>> expected, because currently they never match with "dmIndex" 
>>>>>>> value, since it is always less then 
>>>>>>> "dmPaperToPrintService.length" under "if" statement.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Anton
>>>>>>
>>>>>
>>>>
>>>
>>
>



From jennifer.godinez at oracle.com  Fri Apr 19 21:39:17 2013
From: jennifer.godinez at oracle.com (Jennifer Godinez)
Date: Fri, 19 Apr 2013 14:39:17 -0700
Subject: [OpenJDK 2D-Dev] [8] Review request for 8007642: Media Names on
 Java Print Do Not Match the Printer's and Confuse Users
In-Reply-To: <51716F6E.3090105@oracle.com>
References: <51152343.8060303@oracle.com> <512634FC.8060504@oracle.com>
	<513D98BD.8030201@oracle.com> <5155EAE1.8090208@oracle.com>
	<516E9B34.7080200@oracle.com> <516ED29B.6040503@oracle.com>
	<517063C7.3070601@oracle.com> <51716F6E.3090105@oracle.com>
Message-ID: <5171B985.7070703@oracle.com>

Hi Anton,

I apologize that the cause of the crash is specific to my system.  I 
re-cloned a fresh copy and did not see the crash anymore.  The fix works 
but I have concern that mixing media size names with JDK predefined 
names with printer driver is still confusing for the user.  For one, I 
was able to find a driver,  Brother MFC-J6710, wherein it has 4 types of 
Ledgers (Ledger, Ledger Short Grain, Ledger Borderless, and Ledger 
Borderless/ShortGrain) .  In JDK, it is showing, Ledger, Tabloid, Ledger 
Borderless, and Ledger Borderless/ShortGrain.  I think our use of 
Tabloid is still not right.  I'm leaning towards either changing all the 
names but this is up for discussion.

Jennifer

On 4/19/2013 9:23 AM, Anton Litvinov wrote:
> Hello Jennifer,
>
> I am sorry, but I cannot confirm existence of such a crash, because in 
> my local environment I do not experience any unchecked Java exceptions 
> and JVM crashes. Today I have made a fresh clone of all workspaces 
> from the repository (http://hg.openjdk.java.net/jdk8/jdk8), have 
> applied this fix and have compiled the JDK 8. Also, to be on the safe 
> side, PrimoPDF printer has been reinstalled with the latest version 
> available for downloading from the web site mentioned in my previous 
> e-mail. And I was not able to reproduce your crash neither by 
> scrolling the Media Sizes in Page Setup Dialog, nor by moving in that 
> list using the keyboard.
>
> Did you get this crash with the latest source code of the whole JDK 8 
> patched with the fix? Do you use the test application provided on the 
> bug's record page? Perhaps, you are using a "fastdebug" build of JDK 
> 8, if it is so, then can this kind of build be considered as a 
> reliable for verification of fixes?
>
> Thank you,
> Anton
>
> On 4/19/2013 1:21 AM, Jennifer Godinez wrote:
>> Hi Anton,
>>
>> I got a crash when I tried to go down the list of Media Size in Page 
>> Setup Dialog.  Output is below.  Can you confirm?
>>
>> Jennifer
>>
>> OUTPUT:
>> ---------------------------
>> PrintService = Win32 Printer : PrimoPDF
>> *********************
>> AWT Assertion Failure
>> *********************
>> value != NULL
>> File 'Hashtable.cpp', at line 124
>> GetLastError() is 0 : The operation completed successfully.
>>
>> Do you want to break into the debugger?
>> *********************
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (os_windows_x86.cpp:143), pid=8932, tid=9484
>> #  guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: 
>> Unexpected result f
>> rom topLevelExceptionFilter
>> #
>>
>>
>> On 4/17/2013 9:49 AM, Jennifer Godinez wrote:
>>> Thanks Anton.  I will test your fix and let you know.
>>>
>>> Jennifer
>>>
>>> On 4/17/2013 5:53 AM, Anton Litvinov wrote:
>>>> Hello Jennifer,
>>>>
>>>> Thank you very much for the review of this fix. For reproduction of 
>>>> this bug and testing of the fix the printer "PrimoPDF" with its 
>>>> driver "PrimoPDF" was used. This printer is a virtual printer which 
>>>> generates PDF files as a result of printing jobs and which can be 
>>>> downloaded at the URL (http://www.primopdf.com). Such a printer was 
>>>> selected for testing, because it supports the paper size "11 x 17" 
>>>> in inches, with which the bug was experienced by a user according 
>>>> to the bug report.
>>>>
>>>> Also I was able to observe a similar situation with the printers: 
>>>> "Microsoft XPS Document Writer", "Xerox WorkCentre 4250 GPD PS" but 
>>>> on paper sizes different from "11 x 17". For example, if the 
>>>> printer "Xerox WorkCentre 4250 GPD PS" is used, JDK interprets the 
>>>> paper size "Postcard (100 x 148 mm)" as "Postcard (JIS)" and, when 
>>>> algorithm of the method "sun.print.Win32PrintService.getMediaSizes" 
>>>> encounters the paper size "Japanese Postcard", it interprets it as 
>>>> "Postcard (JIS)" again, which leaves just one media size "Postcard 
>>>> (JIS)" from 2 in Java cross-platform Page Setup and Print dialogs. 
>>>> I think that this situation is similar to the case with "11 x 17" 
>>>> paper size, because some user can also be willing to see exactly 
>>>> "Postcard (100 x 148 mm)" media size in the mentioned Java dialogs, 
>>>> where it will be absent, whoever this fix still will not allow 
>>>> "Postcard (100 x 148 mm)" to be displayed.
>>>>
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 3/29/2013 11:26 PM, Jennifer Godinez wrote:
>>>>> Hi Anton,
>>>>>
>>>>> What printer and printer driver version did you use to test your fix?
>>>>> Thanks.
>>>>>
>>>>> Jennifer
>>>>>
>>>>> On 3/11/2013 1:41 AM, Anton Litvinov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the following fix. This is the second reminder 
>>>>>> message. Please take into account that the original review 
>>>>>> request was sent more than 1 month ago and no response has been 
>>>>>> received yet.
>>>>>>
>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>>
>>>>>> On 2/21/2013 6:53 PM, Anton Litvinov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am sorry for inconvenience. This is a reminder message. I am 
>>>>>>> still interested in reception of the response to this review 
>>>>>>> request and just want to be sure that it is not lost on the mail 
>>>>>>> alias's archive.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Anton
>>>>>>>
>>>>>>> On 2/8/2013 8:09 PM, Anton Litvinov wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review the following fix for a bug.
>>>>>>>>
>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>>>>>>>
>>>>>>>> The bug consists in the fact that Java cross-platform Page 
>>>>>>>> Setup and Print dialogs do not always list all media sizes 
>>>>>>>> supported by a printer. The fix is based on addition of dynamic 
>>>>>>>> creation of new media names of the type 
>>>>>>>> "sun.print.Win32MediaSize" based on paper names received from 
>>>>>>>> Windows API function with corresponding media sizes of the type 
>>>>>>>> "javax.print.attribute.standard.MediaSize" for the case, when 
>>>>>>>> the printer's media size name, which is being analyzed in 
>>>>>>>> "sun.print.Win32PrintService.initMedia" method, is not added to 
>>>>>>>> the final list of media sizes supported by the printer because 
>>>>>>>> of an already existing duplicate in that list. In such a case 
>>>>>>>> the printer's paper size matches with one of the media sizes 
>>>>>>>> registered in JDK, while the paper size ID does not match with 
>>>>>>>> any ID known to JDK.
>>>>>>>>
>>>>>>>> Also the code in "Win32PrintService.findWin32Media" method was 
>>>>>>>> altered to allow three cases from "switch" block to work as 
>>>>>>>> expected, because currently they never match with "dmIndex" 
>>>>>>>> value, since it is always less then 
>>>>>>>> "dmPaperToPrintService.length" under "if" statement.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Anton
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From anthony.petrov at oracle.com  Mon Apr 22 13:02:40 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 22 Apr 2013 17:02:40 +0400
Subject: [OpenJDK 2D-Dev] [8] Review request for 8005607: Recursion in
 J2DXErrHandler() Causes a Stack Overflow on Linux
In-Reply-To: <515373E9.1070609@oracle.com>
References: <50DEF3AC.2070600@oracle.com> <50ED9609.1070002@oracle.com>
	<50EE1CEB.5080500@oracle.com> <50EFED12.6070700@oracle.com>
	<50EFFB4F.4090405@oracle.com> <510946F7.3090709@oracle.com>
	<510A6A54.1080705@oracle.com> <510A90DF.2060501@oracle.com>
	<511BC5E4.9090302@oracle.com> <51220DA4.7040608@oracle.com>
	<512218E7.9090808@oracle.com> <51221D2D.9070907@oracle.com>
	<512251F0.7020204@oracle.com> <5124D315.8080809@oracle.com>
	<51519754.7010906@oracle.com> <5152011C.9070202@oracle.com>
	<51536DE1.1090508@oracle.com> <515373E9.1070609@oracle.com>
Message-ID: <517534F0.3070905@oracle.com>

>> I also do not know the point of saved_error_handler variable, it became unusable with the fix for the bug "6678385", but this seems to be a stable code which I just had to move from XToolkit class to XErrorHandlerUtil without any modification.
>
> So maybe remove it ? Ask the AWT folks what they think.

The variable occupies 8 bytes only. It also allows one to uncomment the 
line:

>  120             // return XlibWrapper.CallErrorHandler(saved_error_handler, display, error.pData);

for debugging purposes w/o having to wire up all the saved_error_handler 
machinery anew. This is needed rarely but may be useful in some cases.

I'd prefer to leave it as is.

--
best regards,
Anthony

On 03/28/13 02:34, Phil Race wrote:
> Hello,
>
> On 3/27/2013 3:08 PM, Anton Litvinov wrote:
>> Hello Phil,
>>
>> Thank you very much for the review. No, the original problem consists
>> in the fact that Xlib function "XSetErrorHandler" is not thread-safe,
>> so calling it from different threads by setting one error handler and
>> restoring the previous error handler leads to
>
> I get that. The MT case is just the mechanism for what I described,
> because the install/restore
> was wrapping the code that needed the special handler.
>
>
>> such not easily reproducible bugs like this and the already fixed
>> 6678385, for example when the second thread restores error handler set
>> by the first thread after the first thread left the code block
>> potentially generating XError and already unset its error handler. The
>> only solution to this problem is introduction of one critical section
>> for all pairs of calls to "XSetErrorHandler" function through
>> WITH_XERROR_HANDLER, RESTORE_XERROR_HANDLER macros in the code of JDK.
>> Even this solution is not complete, because JDK's code cannot
>> influence invoked by it code from the third-party libraries, which
>> also sets or potentially sets own error handlers. The purpose of the
>> fix for "6678385" bug was to guarantee that AWT code sets its global
>> error handler once and for the whole life time of Java application and
>> allows Java code to set "synthetic" or not real error handlers without
>> invocation of "XSetErrorHandler" function. While the idea of this fix
>> is to guarantee that there is no place in JDK other than
>> "src/solaris/native/sun/xawt/XlibWrapper.c", where "XSetErrorHandler"
>> function is called. So this fix substitutes real calls to that native
>> function for setting of "synthetic" error handlers through
>> "sun.awt.X11.XErrorHandlerUtil" class.
>
> Except that 6678385 apparently didn't include the two 2D handlers ? Just
> the XAWT ones.
>
>>
>> Yes, this pattern follows a policy relying on the assumption that no
>> other code has a "more important" need to have its X error handler
>> installed, but with one correction which is "no other code in JDK". So
>> this constraint is not applicable to a code of any third-party
>> library, since it is impossible without collaboration between JDK and
>> third parties on definition of common critical section. Unfortunately,
>> I did not know about the opportunity of embedding Java application
>> into another application.
>
> Isn't that exactly what the SWT /AWT bridge is, which is what started
> off 6678385 ?
> Fortunately that doesn't seem to rely on this behaviour and in fact
> needed 667838.
> But I also wonder about embedding AWT into FX too ..
>
> So I don't know of actual problems for specific apps, but it seems
> theoretically possible.
> If this was already policy for XAWT we likely have this issue anyway so
> I suppose we
> just go with this approach until its proven to be a problem.
>
>>
>> I also do not know the point of saved_error_handler variable, it
>> became unusable with the fix for the bug "6678385", but this seems to
>> be a stable code which I just had to move from XToolkit class to
>> XErrorHandlerUtil without any modification.
>
> So maybe remove it ? Ask the AWT folks what they think.
>
>>
>> AWT_LOCK/AWT_UNLOCK code was added to guarantee that no other thread
>> from JDK code both Java and native can set and unset synthetic error
>> handlers simultaneously. This is the critical section, which I
>> described in my first passage of this e-mail.
>
> That didn't completely answer the point. It wasn't needed before, so did
> you see a real problem ?
> It looked to me like we only get here if we have the AWT_LOCK anyway,
> but I didn't exhaustively trace.
>
> -phil.
>
>>
>> Thank you,
>> Anton
>>
>> On 3/27/2013 12:12 AM, Phil Race wrote:
>>> If I correctly understand the original problem it was that
>>> the restoration of an X Error Handler was expected to be
>>> to the original one installed by the XToolkit but there is
>>> no guarantee of that, so the essence of this fix is
>>> that we install our error handlers as we need them but
>>> then RESTORE_XERROR_HANDLER() is a bit of a misnomer since
>>> it really leaves the handler installed (as far as X11 is concerned)
>>> and in the Java code simply discardscurrent_error_handler.
>>> Then if an error occurs the Java code will fall through to
>>> SAVED_XERROR_HANDLER() which just ignores it.
>>>
>>> I suppose this policy relies on the assumption that no other
>>> code has a "more important" need to have its X error handler
>>> installed, so we have no obligation to restore it after we are done.
>>> I wonder if this is the right thing to do if we are embedded in
>>> another application.
>>>
>>> And I am not sure what the point is of saved_error_handler
>>> in XErrorHandlerUtil.java since you never use it.
>>>
>>>
>>> 561 JNIEnv* env = (JNIEnv*)JNU_GetEnv(jvm, JNI_VERSION_1_2);
>>> 562 AWT_LOCK();
>>> 563 jboolean xShmAttachResult = TryXShmAttach(env, awt_display,
>>> shminfo);
>>> 564 AWT_UNLOCK();
>>>
>>> embedding these declarations in the middle of the function
>>> may trigger a C compiler warning or error depending on the compiler.
>>> Best to move the declarations. Same in the other file.
>>>
>>> I'm curious, why did you add the AWT_LOCK/AWT_UNLOCK which was not
>>> there before?
>>> It may have been considered 'harmless' even if we already have the
>>> lock on this thread and its
>>> a Reentrant lock but it does increase the risk of deadlock, plus its
>>> got JNI up-call overhead ..
>>> but we seem to have a ton of that anyway.
>>>
>>> -phil.
>>>
>>> On 3/26/2013 5:40 AM, Anton Litvinov wrote:
>>>> Hello,
>>>>
>>>> Please review the following fix for a bug. The fix passed 3 cycles
>>>> of review by AWT development team. Artem Ananiev and Anthony Petrov
>>>> approved it. But because the fix modifies also Java 2D Graphics
>>>> code, review by 2D Graphics development team is necessary. New
>>>> "webrev.04" was generated to resolve problem in not smooth patching
>>>> of the latest version of the file
>>>> "src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c".
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005607
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8005607/webrev.04
>>>>
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 2/20/2013 5:43 PM, Artem Ananiev wrote:
>>>>>
>>>>> Looks fine.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Artem
>>>>>
>>>>> On 2/18/2013 8:08 PM, Anton Litvinov wrote:
>>>>>> Hello Artem,
>>>>>>
>>>>>> Could you please review a new version of the fix. The method
>>>>>> "XErrorHandlerUtil.getDisplay()" was removed and
>>>>>> "XErrorHandlerUtil.XSync()" method refers to the field "display"
>>>>>> directly now.
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8005607/webrev.03
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>>
>>>>>> On 2/18/2013 4:23 PM, Artem Ananiev wrote:
>>>>>>>
>>>>>>> On 2/18/2013 4:04 PM, Anton Litvinov wrote:
>>>>>>>> Hello Artem,
>>>>>>>>
>>>>>>>> Thank you very much for the review of this fix. My responses to
>>>>>>>> your
>>>>>>>> questions are provided below in the same order, which you defined.
>>>>>>>>
>>>>>>>> 1. I think that "XErrorHandlerUtil.saved_error" field can surely be
>>>>>>>> marked as private, but in this case the corresponding
>>>>>>>> "XErrorHandlerUtil.getSavedError" method will be necessary, because
>>>>>>>> this field is actively accessed from other classes which set a
>>>>>>>> certain instance of XErrorHandler. For example
>>>>>>>> "MotifDnDDropTargetProtocol.java", "XDragSourceProtocol.java" and a
>>>>>>>> few other classes edited in this fix.
>>>>>>>
>>>>>>> OK, I missed that usages when looking at the webrev. Let it stay
>>>>>>> unchanged now.
>>>>>>>
>>>>>>>> 2. Yes, I completely agree that "XErrorHandlerUtil.getDisplay()" is
>>>>>>>> reduntant. This method will be eliminated.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Artem
>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Anton
>>>>>>>>
>>>>>>>> On 2/18/2013 3:16 PM, Artem Ananiev wrote:
>>>>>>>>> Hi, Anton,
>>>>>>>>>
>>>>>>>>> a few minor comments:
>>>>>>>>>
>>>>>>>>> 1. XErrorHandlerUtil: can saved_error be private instead of
>>>>>>>>> package
>>>>>>>>> protected?
>>>>>>>>>
>>>>>>>>> 2. XErrorHandlerUtil.getDisplay() seems to be redundant.
>>>>>>>>>
>>>>>>>>> In general, the fix looks perfectly fine to me. Please, wait for
>>>>>>>>> comments from Java2D team, though.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Artem
>>>>>>>>>
>>>>>>>>> On 2/13/2013 8:57 PM, Anton Litvinov wrote:
>>>>>>>>>> Hello Anthony,
>>>>>>>>>>
>>>>>>>>>> Could you please review the third version of the fix containing
>>>>>>>>>> modifications discussed with you in the previous letter.
>>>>>>>>>>
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8005607/webrev.02
>>>>>>>>>>
>>>>>>>>>> This version of the fix differs from the previous in the
>>>>>>>>>> following
>>>>>>>>>> places:
>>>>>>>>>>
>>>>>>>>>> 1. A comment about the place of invocation of the method
>>>>>>>>>> "XErrorHandlerUtil.init" was added to a documentation block of
>>>>>>>>>> the
>>>>>>>>>> method.
>>>>>>>>>> 2. A code related to XShmAttach function common to the files
>>>>>>>>>> "src/solaris/native/sun/awt/awt_GraphicsEnv.c" and
>>>>>>>>>> "src/solaris/native/sun/java2d/x11/X11SurfaceData.c" was
>>>>>>>>>> extracted
>>>>>>>>>> into a separate function "TryXShmAttach" declared in
>>>>>>>>>> "src/solaris/native/sun/awt/awt_GraphicsEnv.h" file.
>>>>>>>>>> 3. All JNI code related to X error handling was implemented as
>>>>>>>>>> corresponding macros defined in
>>>>>>>>>> "src/solaris/native/sun/awt/awt_util.h" file.
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Anton
>>>>>>>>>>
>>>>>>>>>> On 1/31/2013 7:42 PM, Anton Litvinov wrote:
>>>>>>>>>>> Hello Anthony,
>>>>>>>>>>>
>>>>>>>>>>> Thank you for the review and these remarks. Surely, the
>>>>>>>>>>> comment will
>>>>>>>>>>> be added. I think that all JNI code related to XShmAttach can be
>>>>>>>>>>> definitely transferred into a separate dedicated function,
>>>>>>>>>>> which will
>>>>>>>>>>> be declared in "src/solaris/native/sun/awt/awt_GraphicsEnv.h"
>>>>>>>>>>> file. I
>>>>>>>>>>> will try to wrap all JNU calls connected with XErrorHandler
>>>>>>>>>>> into the
>>>>>>>>>>> particular "WITH_XERROR_HANDLER", "RESTORE_XERROR_HANDLER"
>>>>>>>>>>> functions
>>>>>>>>>>> or macros.
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Anton
>>>>>>>>>>>
>>>>>>>>>>> On 1/31/2013 4:57 PM, Anthony Petrov wrote:
>>>>>>>>>>>> Hi Anton,
>>>>>>>>>>>>
>>>>>>>>>>>> A couple comments:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. src/solaris/classes/sun/awt/X11/XErrorHandlerUtil.java
>>>>>>>>>>>>> 80 private static void init(long display) {
>>>>>>>>>>>>
>>>>>>>>>>>> This method is private and isn't called from anywhere in
>>>>>>>>>>>> this class
>>>>>>>>>>>> itself. This looks confusing. Please add a comment stating
>>>>>>>>>>>> that this
>>>>>>>>>>>> method is invoked from native code, and from where exactly.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2. Interesting that we use this machinery to call the
>>>>>>>>>>>> XShmAttach()
>>>>>>>>>>>> from native code twice, and the code looks quite similar in
>>>>>>>>>>>> each
>>>>>>>>>>>> case. Would it be possible to extract the common code in a
>>>>>>>>>>>> separate
>>>>>>>>>>>> function (a-la BOOL TryXShmAttach(...)) to avoid code
>>>>>>>>>>>> replication?
>>>>>>>>>>>> There are other usages as well, so we could also introduce a
>>>>>>>>>>>> macro
>>>>>>>>>>>> (such as the old EXEC_WITH_XERROR_HANDLER but now with other
>>>>>>>>>>>> arguments) that would minimize all the JNU_ calls required
>>>>>>>>>>>> to use
>>>>>>>>>>>> this machinery.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Otherwise the fix looks great.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> best regards,
>>>>>>>>>>>> Anthony
>>>>>>>>>>>>
>>>>>>>>>>>> On 1/30/2013 20:14, Anton Litvinov wrote:
>>>>>>>>>>>>> Hello Anthony,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could you, please, review a second version of the fix,
>>>>>>>>>>>>> which is
>>>>>>>>>>>>> based on an idea of reusing the existing AWT native global
>>>>>>>>>>>>> error
>>>>>>>>>>>>> handler from Java 2D native code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Webrev:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8005607/webrev.01
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fix consists of the following parts:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. Migration of all X error handling code from XToolkit to
>>>>>>>>>>>>> a new
>>>>>>>>>>>>> XErrorHandlerUtil class for resolution of interdependency
>>>>>>>>>>>>> between
>>>>>>>>>>>>> a static initialization block of XToolkit and a block
>>>>>>>>>>>>> initializing
>>>>>>>>>>>>> java.awt.GraphicsEnvironment singleton. Such dependency is
>>>>>>>>>>>>> created
>>>>>>>>>>>>> by new calls to XToolkit static methods from
>>>>>>>>>>>>> "src/solaris/native/sun/awt/awt_GraphicsEnv.c",
>>>>>>>>>>>>> "src/solaris/native/sun/java2d/x11/X11SurfaceData.c" files.
>>>>>>>>>>>>> 2. Substitution of XToolkit.WITH_XERROR_HANDLER,
>>>>>>>>>>>>> XToolkit.RESTORE_XERROR_HANDLER ... for corresponding
>>>>>>>>>>>>> methods,
>>>>>>>>>>>>> fields of XErrorHandlerUtil class in all places of JDK source
>>>>>>>>>>>>> code, where they were used.
>>>>>>>>>>>>> 3. Substitution of all found native X error handlers which are
>>>>>>>>>>>>> set in
>>>>>>>>>>>>> native code (awt_GraphicsEnv.c, X11SurfaceData.c,
>>>>>>>>>>>>> GLXSurfaceData.c) for new synthetic Java error handlers.
>>>>>>>>>>>>> 4. Removal of X error handling code used by the native error
>>>>>>>>>>>>> handlers
>>>>>>>>>>>>> from "solaris/native/sun/awt/awt_util.c"
>>>>>>>>>>>>> "solaris/native/sun/awt/awt_util.h" files.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>> Anton
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 1/11/2013 3:45 PM, Anthony Petrov wrote:
>>>>>>>>>>>>>> I'm not Jim, but as I indicated earlier my opinion is that
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> easiest way to fix this is to install the existing
>>>>>>>>>>>>>> J2DXErrHandler()
>>>>>>>>>>>>>> only once. That is, it is the second option listed by you. Of
>>>>>>>>>>>>>> course, the J2DXErrHandler needs to be updated as well to
>>>>>>>>>>>>>> detect
>>>>>>>>>>>>>> whether 2D code wants to use it at the moment or it must
>>>>>>>>>>>>>> simply
>>>>>>>>>>>>>> delegate to the previous handler (i.e. where the code
>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>> installs/uninstalls the handler, it must instead set a global
>>>>>>>>>>>>>> boolean flag or something.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> While the first option (reusing the existing AWT
>>>>>>>>>>>>>> machinery) is an
>>>>>>>>>>>>>> interesting idea in general, I think it is complex and would
>>>>>>>>>>>>>> require too much additional testing and bring an
>>>>>>>>>>>>>> unjustified risk
>>>>>>>>>>>>>> to the solution for such a basic problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 1/11/2013 14:44, Anton Litvinov wrote:
>>>>>>>>>>>>>>> Hello Jim,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you very much for the review and provision of a new
>>>>>>>>>>>>>>> idea of
>>>>>>>>>>>>>>> a solution. Elimination of the logic, which sets/unsets
>>>>>>>>>>>>>>> J2DXErrHandler() for each call "XShmAttach(awt_display,
>>>>>>>>>>>>>>> &shminfo))" should effectively resolve the issue, but
>>>>>>>>>>>>>>> only in
>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>> if all other native error handlers, which were set by the
>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>> function "XSetErrorHandler()" in JDK or in any external
>>>>>>>>>>>>>>> library,
>>>>>>>>>>>>>>> observe the rule of relaying of all events, which are not
>>>>>>>>>>>>>>> relative
>>>>>>>>>>>>>>> to them, to the previously saved error handlers.
>>>>>>>>>>>>>>> Otherwise an
>>>>>>>>>>>>>>> error generated during "XShmAttach" function call will
>>>>>>>>>>>>>>> not be
>>>>>>>>>>>>>>> handled by J2DXErrHandler().
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Could you answer the following question. By setting
>>>>>>>>>>>>>>> J2DXErrHandler() only once and forever do you mean usage
>>>>>>>>>>>>>>> of AWT
>>>>>>>>>>>>>>> global event handler "static int
>>>>>>>>>>>>>>> ToolkitErrorHandler(Display *
>>>>>>>>>>>>>>> dpy, XErrorEvent * event)" from
>>>>>>>>>>>>>>> "src/solaris/native/sun/xawt/XlibWrapper.c" with Java
>>>>>>>>>>>>>>> synthetic
>>>>>>>>>>>>>>> handlers or creation of another global native error
>>>>>>>>>>>>>>> handler with
>>>>>>>>>>>>>>> J2DXErrHandler as native synthetic handler?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>> Anton
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 1/10/2013 5:44 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>> I think I'd rather see some way to prevent double-adding
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> handler in the first place as well. Since it is only
>>>>>>>>>>>>>>>> ever used
>>>>>>>>>>>>>>>> on errors I also think it is OK to set it once and leave it
>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>> forever...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 1/9/13 8:08 AM, Anthony Petrov wrote:
>>>>>>>>>>>>>>>>> Hi Anton et al.,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If I read the description of the bug correctly,
>>>>>>>>>>>>>>>>> specifically
>>>>>>>>>>>>>>>>> this part:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The problem occurs, if another thread (for example, GTK
>>>>>>>>>>>>>>>>>> thread) is
>>>>>>>>>>>>>>>>>> doing the same sort of thing concurrently. This can
>>>>>>>>>>>>>>>>>> lead to
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> following situation.
>>>>>>>>>>>>>>>>>> JVM thread: Sets J2DXErrHandler(), saves
>>>>>>>>>>>>>>>>>> ANY_PREVIOUS_HANDLER as
>>>>>>>>>>>>>>>>>> previous GTK thread: Sets some GTK_HANDLER, saves
>>>>>>>>>>>>>>>>>> J2DXErrHandler() as previous JVM thread: Restores
>>>>>>>>>>>>>>>>>> ANY_PREVIOUS_HANDLER GTK thread: Restores
>>>>>>>>>>>>>>>>>> J2DXErrHandler() JVM
>>>>>>>>>>>>>>>>>> thread: Sets J2DXErrHandler(), saves J2DXErrHandler() as
>>>>>>>>>>>>>>>>>> previous
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is obvious that at this final step 2D is in an
>>>>>>>>>>>>>>>>> inconsistent
>>>>>>>>>>>>>>>>> state. We
>>>>>>>>>>>>>>>>> don't expect to replace our own error handler (and it
>>>>>>>>>>>>>>>>> shouldn't
>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> been there in the first place).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I realize that the fix you propose works around this
>>>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>>> But this
>>>>>>>>>>>>>>>>> doesn't look like an ideal solution to me.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> BTW, IIRC, in JDK7 (and 6?) we decided to set the
>>>>>>>>>>>>>>>>> actual X11
>>>>>>>>>>>>>>>>> error
>>>>>>>>>>>>>>>>> handler only once and never replace it. All the rest of
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> push_handler/pop_handler logic is now located in Java
>>>>>>>>>>>>>>>>> code (see
>>>>>>>>>>>>>>>>> XToolkit.SAVED_ERROR_HANDLER() and the surrounding
>>>>>>>>>>>>>>>>> logic). I
>>>>>>>>>>>>>>>>> believe
>>>>>>>>>>>>>>>>> that we should somehow share this machinery with the 2D
>>>>>>>>>>>>>>>>> code to
>>>>>>>>>>>>>>>>> avoid
>>>>>>>>>>>>>>>>> this sort of problems. Though I'm not sure if this will
>>>>>>>>>>>>>>>>> eliminate this
>>>>>>>>>>>>>>>>> exact issue.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2D/AWT folks: any other thoughts?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 12/29/2012 17:44, Anton Litvinov wrote:
>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please review the following fix for a bug.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Bug:
>>>>>>>>>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005607
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8005607
>>>>>>>>>>>>>>>>>> Webrev:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8005607/webrev.00
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The bug consists in a crash which is caused by a stack
>>>>>>>>>>>>>>>>>> overflow
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> the reason of an infinite recursion in AWT native
>>>>>>>>>>>>>>>>>> function
>>>>>>>>>>>>>>>>>> J2DXErrHandler() under certain circumstances on 32-bit
>>>>>>>>>>>>>>>>>> Linux
>>>>>>>>>>>>>>>>>> OS. The
>>>>>>>>>>>>>>>>>> fix is based on introduction of the logic, which detects
>>>>>>>>>>>>>>>>>> indirect
>>>>>>>>>>>>>>>>>> recursive calls to J2DXErrHandler() by means of a simple
>>>>>>>>>>>>>>>>>> counter, to
>>>>>>>>>>>>>>>>>> J2DXErrHandler() native function. Such a solution
>>>>>>>>>>>>>>>>>> requires
>>>>>>>>>>>>>>>>>> minimum
>>>>>>>>>>>>>>>>>> code changes, does not alter the handler's code
>>>>>>>>>>>>>>>>>> significantly
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> eliminates this bug.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Adding 2d-dev at openjdk.java.net e-mail alias to the
>>>>>>>>>>>>>>>>>> list of
>>>>>>>>>>>>>>>>>> recipients
>>>>>>>>>>>>>>>>>> of this letter, because the edited function's name is
>>>>>>>>>>>>>>>>>> related
>>>>>>>>>>>>>>>>>> to Java
>>>>>>>>>>>>>>>>>> 2D area of JDK, despite of the fact that the edited
>>>>>>>>>>>>>>>>>> file is
>>>>>>>>>>>>>>>>>> located in
>>>>>>>>>>>>>>>>>> AWT directory.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>>>> Anton
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>>
>


From james.graham at oracle.com  Mon Apr 22 21:05:21 2013
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 22 Apr 2013 14:05:21 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: 
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
	
	
Message-ID: <5175A611.9080004@oracle.com>

One thing about modifying the iterators.  I originally commented that I 
thought an object there was a bit much but it helped Denis, who was 
doing all the work after all, keep the code organized in his mind.  I'm 
not sure what kind of measurements he made, but he didn't feel that they 
were hurting performance at the time.  If you are finding that the 
allocation of the iterators is costing us then I'd just as much like to 
see that paradigm go away, though your fix to allocate them once and 
then re-init them does save the memory costs.

Other renderers I've worked on an written have done essentially the same 
work inline rather than farming it out to another object.

I also think it's a good suggestion to keep fixes on code like this more 
focused on isolating the fix itself rather than reorganizing the code to 
a personal style to fix a few issues.  So, as far as the code 
organization changes I agree with Clemens there.  When it comes down to 
"a quick fix that doesn't touch many lines of code" like your init() 
solution vs. "rewriting that part of the code to no longer need the 
operations that were causing problems" then it gets grayer.  I would 
have probably eliminated the iterators altogether because I would view 
it as reducing the complexity of the code, but your solution would 
probably touch fewer lines of code (if you factor out the 
reorganization).  I at least wanted to throw that idea out as a 
suggestion...

			...jim

On 4/17/13 9:52 PM, Laurent Bourg?s wrote:
> Hi clemens
>
> Le 17 avr. 2013 23:16, "Clemens Eisserer"  > a ?crit :
>>
>> Hi Laurent,
>>
>>> thanks for having some interest for my efforts !
>>> As I got almost no feedback, I felt quite disappointed and was thinking that improving pisces was not important ...
>>
>>
>> Glad to see work is ongoing to improve pisces's performance :)
>>
>
> Thanks a lot: I am working on pisces during my spare time and
> congratulations is very important for my motivation.
>
>> I had a look at the patch just to be curious (I don't have reviewer status), but to be honest I had troubles finding the relevant parts.
>
> I agree I modify the code to help me understanding it : @override,
> grouped fields, constant first, debug logs ...
>
> I can revert most of these boilerplates ... during cleanup.
>
> I sent the patch as webrev to let other people evaluate its performance
> using their own platform, work load, benchmarks ...
>
>> Having not followed the discussion that closely, it was almost impossible for me to extract the real modifications from boilerplate/refactoring as your patch weights almost 3000 modified lines.
>
> I looked at the webrev and I advocate I can discard many line changes.
> As I use netbeans, it modified the code so easily... nevermind.
>
>> I am just an intrested observer without any official state, yet personally I would prefer smaller pieces with clear description/title.
>> However, I wouldn't want to cause you additional work and it's just a single opinion.
>>
>
> Ok. I mainly modified memory handling: use a renderer cache to reuse
> arrays and pisces class instances to avoid too much allocations and
> resizing ... stored in thread local or concurrent queue.
>
>> Thanks for working on pisces!
>
> Thanks for your feedback too.
>
> Laurent
>
>>
>> Regards, Clemens
>>
>>
>


From james.graham at oracle.com  Mon Apr 22 21:11:14 2013
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 22 Apr 2013 14:11:14 -0700
Subject: [OpenJDK 2D-Dev] [8] Request for review: 8004859
 Graphics.getClipBounds/getClip return difference nonequivalent bounds,
 depending from transform.
In-Reply-To: <516FF424.4010900@oracle.com>
References: <50C9B74A.7050806@oracle.com> <50CA3D30.5020104@oracle.com>
	<50CCB2CA.8030307@oracle.com> <50D29862.2060806@oracle.com>
	<50D2DF22.7020007@oracle.com> <50D2E484.3030004@oracle.com>
	<50D35065.1080307@oracle.com> <50D38628.2050807@oracle.com>
	<50D39EA4.6050802@oracle.com> <50D3A0B1.2040407@oracle.com>
	<50D3A530.4070604@oracle.com> <50D3B083.800@oracle.com>
	<50D3B45F.4010903@oracle.com> <50D3C3D5.7080506@oracle.com>
	<50D4464F.8050401@oracle.com> <50E4DA79.7020703@oracle.com>
	<50F46025.7080705@oracle.com> <50F74C49.9000800@oracle.com>
	<516FF424.4010900@oracle.com>
Message-ID: <5175A772.2020503@oracle.com>

I think if empty (un)transforms to something else that is also 
classified as empty naturally without having to special case it or test 
it then returning the "transformed empty thing" is a fine return value.

But, if it comes down to "Eeek, it was empty so I need to calculate a 
specifically similar empty thing to return" then I feel that the test 
should just result in "return new Rectangle()".  No use pulling hair out 
to make a "more useful non-answer" unless it falls out of the 
calculations for free - as in "unless it avoids even having to check for 
the exceptional condition in the first place".  In the cases I reviewed 
I seem to recall that we were doing the tests anyway (or we were doing 
equally complex tests in order to normalize the answer even if we never 
explicitly tested for "isEmpty()") so it would make the code much less 
problematic to just weed the empty answers out early.

As far as "are any Developers expecting a usefully non-degenerate empty 
answer" then I don't think so...

			...jim

On 4/18/13 6:24 AM, Sergey Bylokhov wrote:
> Hello Jim.
>
> On 1/17/13 4:56 AM, Jim Graham wrote:
>> The original code in getClipBounds would end up returning a "new
>> Rectangle()" if the clip was an empty rectangle due to the way that
>> "Rectangle2D/Path2D.getBounds()" works.  You now use
>> setFrame(getBounds2D()) which will attempt to preserve the dimensions
>> of empty clips.  So, the "preserve the size of an empty clip" support
>> is new.
>>
>> I then mentioned that we don't need to go out of our way to preserve
>> the dimensions of an empty clip, but you seem to be saying that we
>> don't want to change this behavior - but your new code represents the
>> break with existing behaviors, no?
> I returned to this problem and studied it a little more deeply.
> Description.
> Assume we set clip=Rectangle[100, 100,-100,-100] for sg2d with a
> different transform.
>   1 identity/translate (default mode for non-retina): getClip () will
> return Rectangle[100, 100,-100,-100].
>   2 scale (default mode for retina): getClip() will return
> Rectangle[0,0,100,100] <- bug and it should be fixed.
>   3 generic: getClip will return Rectangle[0,0,0,0], because we convert
> Rectangle to the Shape through RectIterator, which ignores the negative
> width and height. Note that x and y were not preserved only if w and
> h<0, but if w = h =0, then x and y will be preserved.
>
> In an original fix I made case 2 like case 1, so from the point of view
> of users there was no difference in case of retina display.
> But now I have doubts and I think that all cases shall work equally like
> in case 3.
> What do you think?
>
>>
>>             ...jim
>
>


From james.graham at oracle.com  Mon Apr 22 21:13:25 2013
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 22 Apr 2013 14:13:25 -0700
Subject: [OpenJDK 2D-Dev] Fix proposal for UnixPrintServiceLookup not
 returning consistent values
In-Reply-To: 
References: <921DCFDE-B4B9-4E51-A95E-6439111A7AC4@reini.net>
	<1366229461.2858.4.camel@wsccuw01.ccuw.ch>
	
Message-ID: <5175A7F5.6070208@oracle.com>

Hi Patrick,

Since the fix involves printing it may be better to work through Phil 
Race since that is more his area.  He can hook you up with the necessary 
"paperwork" and review/integrate your fixes...

			...jim

On 4/18/13 11:18 AM, Patrick Reinhart wrote:
> Hi James,
>
> I'm new on this list and would like to submit a fix. Unfortunately I did not received the bug number for my submitted problem, where I think I got a fix for.
>
> Could you help me on this?
>
> Cheers
>
> Patrick
>
> Am 17.04.2013 um 22:11 schrieb Patrick Reinhart :
>
>> On Tue, 2013-04-16 at 14:15 +0200, Patrick Reinhart wrote:
>>
>> Here's the link to suggested fix:
>>
>> http://reinharts.dyndns.org/webrev/
>>
>> Cheers Patrick


From patrick at reini.net  Tue Apr 23 04:42:09 2013
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 23 Apr 2013 06:42:09 +0200
Subject: [OpenJDK 2D-Dev] Fix proposal for 9001948: UnixPrintServiceLookup
	not returning consistent values
In-Reply-To: <5175A7F5.6070208@oracle.com>
References: <921DCFDE-B4B9-4E51-A95E-6439111A7AC4@reini.net>
	<1366229461.2858.4.camel@wsccuw01.ccuw.ch>
	
	<5175A7F5.6070208@oracle.com>
Message-ID: <7ED39034-6E81-4274-89F1-CBC9B15321AE@reini.net>

Hi Jim,
Hi Phil

I just submitted the bug description yesterday again and now recveived a number:

9001948

I guess the first time it somehow did not work. I already adjusted the test in ny fix proposal:

http://reinharts.dyndns.org/webrev

Cheers Patrick

Am 22.04.2013 um 23:13 schrieb Jim Graham :

> Hi Patrick,
> 
> Since the fix involves printing it may be better to work through Phil Race since that is more his area.  He can hook you up with the necessary "paperwork" and review/integrate your fixes...
> 
>           ...jim
> 
> On 4/18/13 11:18 AM, Patrick Reinhart wrote:
>> Hi James,
>> 
>> I'm new on this list and would like to submit a fix. Unfortunately I did not received the bug number for my submitted problem, where I think I got a fix for.
>> 
>> Could you help me on this?
>> 
>> Cheers
>> 
>> Patrick
>> 
>> Am 17.04.2013 um 22:11 schrieb Patrick Reinhart :
>> 
>>> On Tue, 2013-04-16 at 14:15 +0200, Patrick Reinhart wrote:
>>> 
>>> Here's the link to suggested fix:
>>> 
>>> http://reinharts.dyndns.org/webrev/
>>> 
>>> Cheers Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From anton.litvinov at oracle.com  Tue Apr 23 15:19:40 2013
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Tue, 23 Apr 2013 19:19:40 +0400
Subject: [OpenJDK 2D-Dev] [8] Review request for 8007642: Media Names on
 Java Print Do Not Match the Printer's and Confuse Users
In-Reply-To: <5171B985.7070703@oracle.com>
References: <51152343.8060303@oracle.com> <512634FC.8060504@oracle.com>
	<513D98BD.8030201@oracle.com> <5155EAE1.8090208@oracle.com>
	<516E9B34.7080200@oracle.com> <516ED29B.6040503@oracle.com>
	<517063C7.3070601@oracle.com> <51716F6E.3090105@oracle.com>
	<5171B985.7070703@oracle.com>
Message-ID: <5176A68C.2040604@oracle.com>

Hello Jennifer,

Thank you for clarification of your situation with JVM crash. I am very 
glad to know that it was not caused by the fix and that you managed to 
evaluate it. I tried to test the fix with the printer driver "Brother 
MFC-J6710DW", which you specified in your previous e-mail. I also was 
able to reproduce the situation with absence of the media size "Ledger 
(Short Grain)(11 x 17 in)" in Java Page Setup dialog, but debugging 
showed that this media size was displayed as "Ledger" and "Ledger (11 x 
17 in)" was considered as "Tabloid", because its paper ID equaled "3", 
which is really "Tabloid". So, probably, other native applications, 
whose page setup dialogs show "Ledger (11 x 17 in)" instead of 
"Tabloid", simply print out media size names returned by the driver, 
therefore I suppose that exactly this media size is problematic because 
of the driver, which supplies either the wrong paper ID or the wrong 
paper name. I created an improved second version of the fix. Could you 
please review it.

Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.01

Differences between this fix and its previous version are the following:

1. Static initialization block of Win32PrintService class was removed, 
because its internal call

     86         Class c = Win32MediaSize.class;

did not lead to initialization of the static variable "predefMedia" from 
a static initialization block of Win32MediaSize class. Such situation is 
the reason of constant returning of null values from

     623           msn = findMatchingMediaSizeNameMM(wid, ht);

for each first iteration of the for loop in 
"Win32PrintService.getMediaSizes" method. As a solution for this problem 
"predefMedia" started being initialized by a direct call to the new 
"Win32MediaSize.getPredefMedia" method, which guarantees that before its 
execution the static initialization block of Win32MediaSize class is 
already executed.

2. Additional changes in the method "Win32PrintService.initMedia" 
guarantee that a media size name provided by the printer's driver is 
always added to "msnList" local variable, if a paper ID does not match 
with any paper ID predefined in JDK (the call 
"findWin32Media(((Integer)idList.get(i)).intValue());"). This change 
makes it possible to display "Ledger (Short Grain)(11 x 17 in)" media 
size with the driver "Brother MFC-J6710DW". So in certain cases this fix 
leads to displaying of 2 media size names for one media size: 1 media 
size name registered in JDK, whose media size matches with this media 
size,  1 new media size name constructed from a string returned by the 
driver. Testing in my local environment with all earlier mentioned 
printers showed that cases of presence of such pairs of media size names 
are very rare, while they help users to find the required media sizes in 
Java Page Setup Dialog.

Thank you,
Anton

On 4/20/2013 1:39 AM, Jennifer Godinez wrote:
> Hi Anton,
>
> I apologize that the cause of the crash is specific to my system. I 
> re-cloned a fresh copy and did not see the crash anymore.  The fix 
> works but I have concern that mixing media size names with JDK 
> predefined names with printer driver is still confusing for the user.  
> For one, I was able to find a driver,  Brother MFC-J6710, wherein it 
> has 4 types of Ledgers (Ledger, Ledger Short Grain, Ledger Borderless, 
> and Ledger Borderless/ShortGrain) .  In JDK, it is showing, Ledger, 
> Tabloid, Ledger Borderless, and Ledger Borderless/ShortGrain.  I think 
> our use of Tabloid is still not right.  I'm leaning towards either 
> changing all the names but this is up for discussion.
>
> Jennifer
>
> On 4/19/2013 9:23 AM, Anton Litvinov wrote:
>> Hello Jennifer,
>>
>> I am sorry, but I cannot confirm existence of such a crash, because 
>> in my local environment I do not experience any unchecked Java 
>> exceptions and JVM crashes. Today I have made a fresh clone of all 
>> workspaces from the repository 
>> (http://hg.openjdk.java.net/jdk8/jdk8), have applied this fix and 
>> have compiled the JDK 8. Also, to be on the safe side, PrimoPDF 
>> printer has been reinstalled with the latest version available for 
>> downloading from the web site mentioned in my previous e-mail. And I 
>> was not able to reproduce your crash neither by scrolling the Media 
>> Sizes in Page Setup Dialog, nor by moving in that list using the 
>> keyboard.
>>
>> Did you get this crash with the latest source code of the whole JDK 8 
>> patched with the fix? Do you use the test application provided on the 
>> bug's record page? Perhaps, you are using a "fastdebug" build of JDK 
>> 8, if it is so, then can this kind of build be considered as a 
>> reliable for verification of fixes?
>>
>> Thank you,
>> Anton
>>
>> On 4/19/2013 1:21 AM, Jennifer Godinez wrote:
>>> Hi Anton,
>>>
>>> I got a crash when I tried to go down the list of Media Size in Page 
>>> Setup Dialog.  Output is below.  Can you confirm?
>>>
>>> Jennifer
>>>
>>> OUTPUT:
>>> ---------------------------
>>> PrintService = Win32 Printer : PrimoPDF
>>> *********************
>>> AWT Assertion Failure
>>> *********************
>>> value != NULL
>>> File 'Hashtable.cpp', at line 124
>>> GetLastError() is 0 : The operation completed successfully.
>>>
>>> Do you want to break into the debugger?
>>> *********************
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  Internal Error (os_windows_x86.cpp:143), pid=8932, tid=9484
>>> #  guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: 
>>> Unexpected result f
>>> rom topLevelExceptionFilter
>>> #
>>>
>>>
>>> On 4/17/2013 9:49 AM, Jennifer Godinez wrote:
>>>> Thanks Anton.  I will test your fix and let you know.
>>>>
>>>> Jennifer
>>>>
>>>> On 4/17/2013 5:53 AM, Anton Litvinov wrote:
>>>>> Hello Jennifer,
>>>>>
>>>>> Thank you very much for the review of this fix. For reproduction 
>>>>> of this bug and testing of the fix the printer "PrimoPDF" with its 
>>>>> driver "PrimoPDF" was used. This printer is a virtual printer 
>>>>> which generates PDF files as a result of printing jobs and which 
>>>>> can be downloaded at the URL (http://www.primopdf.com). Such a 
>>>>> printer was selected for testing, because it supports the paper 
>>>>> size "11 x 17" in inches, with which the bug was experienced by a 
>>>>> user according to the bug report.
>>>>>
>>>>> Also I was able to observe a similar situation with the printers: 
>>>>> "Microsoft XPS Document Writer", "Xerox WorkCentre 4250 GPD PS" 
>>>>> but on paper sizes different from "11 x 17". For example, if the 
>>>>> printer "Xerox WorkCentre 4250 GPD PS" is used, JDK interprets the 
>>>>> paper size "Postcard (100 x 148 mm)" as "Postcard (JIS)" and, when 
>>>>> algorithm of the method 
>>>>> "sun.print.Win32PrintService.getMediaSizes" encounters the paper 
>>>>> size "Japanese Postcard", it interprets it as "Postcard (JIS)" 
>>>>> again, which leaves just one media size "Postcard (JIS)" from 2 in 
>>>>> Java cross-platform Page Setup and Print dialogs. I think that 
>>>>> this situation is similar to the case with "11 x 17" paper size, 
>>>>> because some user can also be willing to see exactly "Postcard 
>>>>> (100 x 148 mm)" media size in the mentioned Java dialogs, where it 
>>>>> will be absent, whoever this fix still will not allow "Postcard 
>>>>> (100 x 148 mm)" to be displayed.
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>>
>>>>> On 3/29/2013 11:26 PM, Jennifer Godinez wrote:
>>>>>> Hi Anton,
>>>>>>
>>>>>> What printer and printer driver version did you use to test your 
>>>>>> fix?
>>>>>> Thanks.
>>>>>>
>>>>>> Jennifer
>>>>>>
>>>>>> On 3/11/2013 1:41 AM, Anton Litvinov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the following fix. This is the second reminder 
>>>>>>> message. Please take into account that the original review 
>>>>>>> request was sent more than 1 month ago and no response has been 
>>>>>>> received yet.
>>>>>>>
>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Anton
>>>>>>>
>>>>>>> On 2/21/2013 6:53 PM, Anton Litvinov wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I am sorry for inconvenience. This is a reminder message. I am 
>>>>>>>> still interested in reception of the response to this review 
>>>>>>>> request and just want to be sure that it is not lost on the 
>>>>>>>> mail alias's archive.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Anton
>>>>>>>>
>>>>>>>> On 2/8/2013 8:09 PM, Anton Litvinov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review the following fix for a bug.
>>>>>>>>>
>>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007642
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8007642/webrev.00
>>>>>>>>>
>>>>>>>>> The bug consists in the fact that Java cross-platform Page 
>>>>>>>>> Setup and Print dialogs do not always list all media sizes 
>>>>>>>>> supported by a printer. The fix is based on addition of 
>>>>>>>>> dynamic creation of new media names of the type 
>>>>>>>>> "sun.print.Win32MediaSize" based on paper names received from 
>>>>>>>>> Windows API function with corresponding media sizes of the 
>>>>>>>>> type "javax.print.attribute.standard.MediaSize" for the case, 
>>>>>>>>> when the printer's media size name, which is being analyzed in 
>>>>>>>>> "sun.print.Win32PrintService.initMedia" method, is not added 
>>>>>>>>> to the final list of media sizes supported by the printer 
>>>>>>>>> because of an already existing duplicate in that list. In such 
>>>>>>>>> a case the printer's paper size matches with one of the media 
>>>>>>>>> sizes registered in JDK, while the paper size ID does not 
>>>>>>>>> match with any ID known to JDK.
>>>>>>>>>
>>>>>>>>> Also the code in "Win32PrintService.findWin32Media" method was 
>>>>>>>>> altered to allow three cases from "switch" block to work as 
>>>>>>>>> expected, because currently they never match with "dmIndex" 
>>>>>>>>> value, since it is always less then 
>>>>>>>>> "dmPaperToPrintService.length" under "if" statement.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Anton
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From philip.race at oracle.com  Tue Apr 23 16:27:20 2013
From: philip.race at oracle.com (Phil Race)
Date: Tue, 23 Apr 2013 09:27:20 -0700
Subject: [OpenJDK 2D-Dev] Fix proposal for 9001948:
 UnixPrintServiceLookup not returning consistent values
In-Reply-To: <7ED39034-6E81-4274-89F1-CBC9B15321AE@reini.net>
References: <921DCFDE-B4B9-4E51-A95E-6439111A7AC4@reini.net>
	<1366229461.2858.4.camel@wsccuw01.ccuw.ch>
	
	<5175A7F5.6070208@oracle.com>
	<7ED39034-6E81-4274-89F1-CBC9B15321AE@reini.net>
Message-ID: <5176B668.7040405@oracle.com>

That's a Java incident number, not a JDK bug number.
JDK numbers begin with "JDK-8", incident numbers begin with "JI-9"
I imagine jcheck will reject use of that number - it should !
I asked Jennifer to look into this right after you first posted.
Jennifer ?

Off hand I'm not sure I like the proposed patch since it seems to ignore
the point of the existing comment at lines 359-362 ..

-phil.

On 4/22/2013 9:42 PM, Patrick Reinhart wrote:
> Hi Jim,
> Hi Phil
>
> I just submitted the bug description yesterday again and now recveived 
> a number:
>
> 9001948
>
> I guess the first time it somehow did not work. I already adjusted the 
> test in ny fix proposal:
>
> http://reinharts.dyndns.org/webrev
>
> Cheers Patrick
>
> Am 22.04.2013 um 23:13 schrieb Jim Graham  >:
>
>> Hi Patrick,
>>
>> Since the fix involves printing it may be better to work through Phil 
>> Race since that is more his area.  He can hook you up with the 
>> necessary "paperwork" and review/integrate your fixes...
>>
>>           ...jim
>>
>> On 4/18/13 11:18 AM, Patrick Reinhart wrote:
>>> Hi James,
>>>
>>> I'm new on this list and would like to submit a fix. Unfortunately I 
>>> did not received the bug number for my submitted problem, where I 
>>> think I got a fix for.
>>>
>>> Could you help me on this?
>>>
>>> Cheers
>>>
>>> Patrick
>>>
>>> Am 17.04.2013 um 22:11 schrieb Patrick Reinhart >> >:
>>>
>>>> On Tue, 2013-04-16 at 14:15 +0200, Patrick Reinhart wrote:
>>>>
>>>> Here's the link to suggested fix:
>>>>
>>>> http://reinharts.dyndns.org/webrev/
>>>>
>>>> Cheers Patrick



From jennifer.godinez at oracle.com  Tue Apr 23 16:56:40 2013
From: jennifer.godinez at oracle.com (Jennifer Godinez)
Date: Tue, 23 Apr 2013 09:56:40 -0700
Subject: [OpenJDK 2D-Dev] Fix proposal for 9001948:
 UnixPrintServiceLookup not returning consistent values
In-Reply-To: <5176B668.7040405@oracle.com>
References: <921DCFDE-B4B9-4E51-A95E-6439111A7AC4@reini.net>
	<1366229461.2858.4.camel@wsccuw01.ccuw.ch>
	
	<5175A7F5.6070208@oracle.com>
	<7ED39034-6E81-4274-89F1-CBC9B15321AE@reini.net>
	<5176B668.7040405@oracle.com>
Message-ID: <5176BD48.6060704@oracle.com>

Hi Phil,

I haven't confirmed this.  I was about to ask for the program but now I 
see it is included in the webrev.  I'll let you know.

Jennifer

On 4/23/2013 9:27 AM, Phil Race wrote:
> That's a Java incident number, not a JDK bug number.
> JDK numbers begin with "JDK-8", incident numbers begin with "JI-9"
> I imagine jcheck will reject use of that number - it should !
> I asked Jennifer to look into this right after you first posted.
> Jennifer ?
>
> Off hand I'm not sure I like the proposed patch since it seems to ignore
> the point of the existing comment at lines 359-362 ..
>
> -phil.
>
> On 4/22/2013 9:42 PM, Patrick Reinhart wrote:
>> Hi Jim,
>> Hi Phil
>>
>> I just submitted the bug description yesterday again and now 
>> recveived a number:
>>
>> 9001948
>>
>> I guess the first time it somehow did not work. I already adjusted 
>> the test in ny fix proposal:
>>
>> http://reinharts.dyndns.org/webrev
>>
>> Cheers Patrick
>>
>> Am 22.04.2013 um 23:13 schrieb Jim Graham > >:
>>
>>> Hi Patrick,
>>>
>>> Since the fix involves printing it may be better to work through 
>>> Phil Race since that is more his area.  He can hook you up with the 
>>> necessary "paperwork" and review/integrate your fixes...
>>>
>>>           ...jim
>>>
>>> On 4/18/13 11:18 AM, Patrick Reinhart wrote:
>>>> Hi James,
>>>>
>>>> I'm new on this list and would like to submit a fix. Unfortunately 
>>>> I did not received the bug number for my submitted problem, where I 
>>>> think I got a fix for.
>>>>
>>>> Could you help me on this?
>>>>
>>>> Cheers
>>>>
>>>> Patrick
>>>>
>>>> Am 17.04.2013 um 22:11 schrieb Patrick Reinhart >>> >:
>>>>
>>>>> On Tue, 2013-04-16 at 14:15 +0200, Patrick Reinhart wrote:
>>>>>
>>>>> Here's the link to suggested fix:
>>>>>
>>>>> http://reinharts.dyndns.org/webrev/
>>>>>
>>>>> Cheers Patrick
>



From patrick at reini.net  Tue Apr 23 19:47:33 2013
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 23 Apr 2013 21:47:33 +0200
Subject: [OpenJDK 2D-Dev] Fix proposal for 9001948:
 UnixPrintServiceLookup not returning consistent values
In-Reply-To: <5176BD48.6060704@oracle.com>
References: <921DCFDE-B4B9-4E51-A95E-6439111A7AC4@reini.net>
	<1366229461.2858.4.camel@wsccuw01.ccuw.ch>
	
	<5175A7F5.6070208@oracle.com>
	<7ED39034-6E81-4274-89F1-CBC9B15321AE@reini.net>
	<5176B668.7040405@oracle.com> <5176BD48.6060704@oracle.com>
Message-ID: <1366746453.13371.8.camel@wsccuw01.ccuw.ch>

Hi Phil,

On Tue, 2013-04-23 at 09:56 -0700, Jennifer Godinez wrote:
> Hi Phil,
> 
> I haven't confirmed this.  I was about to ask for the program but now I 
> see it is included in the webrev.  I'll let you know.
> 
> Jennifer
> 
> On 4/23/2013 9:27 AM, Phil Race wrote:
> > That's a Java incident number, not a JDK bug number.
> > JDK numbers begin with "JDK-8", incident numbers begin with "JI-9"
> > I imagine jcheck will reject use of that number - it should !

This is not the case as I did run the test before and after my fix to
prove that it works. Thanks anyway for the hint.

> > I asked Jennifer to look into this right after you first posted.
> > Jennifer ?
> >
> > Off hand I'm not sure I like the proposed patch since it seems to ignore
> > the point of the existing comment at lines 359-362 ..

Good point! I missed that by the excitement about my fix ;-)  I did take
this in account now and updated my webrev accordingly.

I introduced a createPrintService() method that replaces 3 identical
code parts within the existing UnixPrintServiceLookup and used this
method now on the existing getNamedPrinterNameBSD() and
getNamedPrinterNameSysV() methods.

Cheers Patrick



From iris.clark at oracle.com  Tue Apr 23 20:22:40 2013
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 23 Apr 2013 13:22:40 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] Fix proposal for 9001948:
 UnixPrintServiceLookup not returning consistent values
In-Reply-To: <5176B668.7040405@oracle.com>
References: <921DCFDE-B4B9-4E51-A95E-6439111A7AC4@reini.net>
	<1366229461.2858.4.camel@wsccuw01.ccuw.ch>
	
	<5175A7F5.6070208@oracle.com>
	<7ED39034-6E81-4274-89F1-CBC9B15321AE@reini.net>
	<5176B668.7040405@oracle.com>
Message-ID: 

Hi, Phil.

http://hg.openjdk.java.net/code-tools/jcheck/file/8ca0fb80367b/jcheck.py

See lines 154-155.  If bug validation is enabled it will reject bugids beginning with "9".

Thanks,
iris

-----Original Message-----
From: Phil Race 
Sent: Tuesday, April 23, 2013 9:27 AM
To: Patrick Reinhart
Cc: Jim Graham; 2d-dev at openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] Fix proposal for 9001948: UnixPrintServiceLookup not returning consistent values

That's a Java incident number, not a JDK bug number.
JDK numbers begin with "JDK-8", incident numbers begin with "JI-9"
I imagine jcheck will reject use of that number - it should !
I asked Jennifer to look into this right after you first posted.
Jennifer ?

Off hand I'm not sure I like the proposed patch since it seems to ignore the point of the existing comment at lines 359-362 ..

-phil.


From bourges.laurent at gmail.com  Tue Apr 23 21:58:28 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Tue, 23 Apr 2013 23:58:28 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: <5175A611.9080004@oracle.com>
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
	
	
	<5175A611.9080004@oracle.com>
Message-ID: 

Jim,

I am preparing an updated patch that will contain less syntax changes and
boiler plates. Sorry again.

I have optimized few array cleaning and it perform as fast as ductus on the
biggest map test : in average equals !!

i will send results and comparisons tomorrow.

Hint: alpha array cleaning in renderer endRendering can be optimized by
filling only dirty part as i already do in the given patch. This small
change can be applied easily...

Le 22 avr. 2013 23:05, "Jim Graham"  a ?crit :
>
> One thing about modifying the iterators.  I originally commented that I
thought an object there was a bit much but it helped Denis, who was doing
all the work after all, keep the code organized in his mind.  I'm not sure
what kind of measurements he made, but he didn't feel that they were
hurting performance at the time.  If you are finding that the allocation of
the iterators is costing us then I'd just as much like to see that paradigm
go away, though your fix to allocate them once and then re-init them does
save the memory costs.
>
> Other renderers I've worked on an written have done essentially the same
work inline rather than farming it out to another object.
>
> I also think it's a good suggestion to keep fixes on code like this more
focused on isolating the fix itself rather than reorganizing the code to a
personal style to fix a few issues.  So, as far as the code organization
changes I agree with Clemens there.  When it comes down to "a quick fix
that doesn't touch many lines of code" like your init() solution vs.
"rewriting that part of the code to no longer need the operations that were
causing problems" then it gets grayer.  I would have probably eliminated
the iterators altogether because I would view it as reducing the complexity
of the code, but your solution would probably touch fewer lines of code (if
you factor out the reorganization).  I at least wanted to throw that idea
out as a suggestion..

Agreed. I will try to provide smaller changes but it is difficult to
isolate efficient changes.

Last idea: I think reusing arrays is efficient because they reside in the
cpu cache... and less gc.

I would like to try perform the rendering / cache / tile generation by
chunks corresponding to 32 scan lines to have / reuse a smaller rowAARLE
array...

Finally I looked a bit at clipping shapes and I think it should be done
first in the Stroker segment processing.

Regards,
Laurent

>
>                         ...jim
>
>
> On 4/17/13 9:52 PM, Laurent Bourg?s wrote:
>>
>> Hi clemens
>>
>> Le 17 avr. 2013 23:16, "Clemens Eisserer" > > a ?crit :
>>
>>>
>>> Hi Laurent,
>>>
>>>> thanks for having some interest for my efforts !
>>>> As I got almost no feedback, I felt quite disappointed and was
thinking that improving pisces was not important ...
>>>
>>>
>>>
>>> Glad to see work is ongoing to improve pisces's performance :)
>>>
>>
>> Thanks a lot: I am working on pisces during my spare time and
>> congratulations is very important for my motivation.
>>
>>> I had a look at the patch just to be curious (I don't have reviewer
status), but to be honest I had troubles finding the relevant parts.
>>
>>
>> I agree I modify the code to help me understanding it : @override,
>> grouped fields, constant first, debug logs ...
>>
>> I can revert most of these boilerplates ... during cleanup.
>>
>> I sent the patch as webrev to let other people evaluate its performance
>> using their own platform, work load, benchmarks ...
>>
>>> Having not followed the discussion that closely, it was almost
impossible for me to extract the real modifications from
boilerplate/refactoring as your patch weights almost 3000 modified lines.
>>
>>
>> I looked at the webrev and I advocate I can discard many line changes.
>> As I use netbeans, it modified the code so easily... nevermind.
>>
>>> I am just an intrested observer without any official state, yet
personally I would prefer smaller pieces with clear description/title.
>>> However, I wouldn't want to cause you additional work and it's just a
single opinion.
>>>
>>
>> Ok. I mainly modified memory handling: use a renderer cache to reuse
>> arrays and pisces class instances to avoid too much allocations and
>> resizing ... stored in thread local or concurrent queue.
>>
>>> Thanks for working on pisces!
>>
>>
>> Thanks for your feedback too.
>>
>> Laurent
>>
>>>
>>> Regards, Clemens
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From james.graham at oracle.com  Wed Apr 24 01:24:45 2013
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 23 Apr 2013 18:24:45 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: 
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
	
	
	<5175A611.9080004@oracle.com>
	
Message-ID: <5177345D.4060408@oracle.com>

Hi Laurent,

Originally the version that was used in embedded used RLE because it 
stored the results in the shape itself.  On desktop I never found that 
to be a necessary optimization especially because it actually wastes 
memory for no gain during animations, but that was why they used RLE as 
a storage format.  Would it speed up the code to use a different storage 
format?

Also, in the version we use in JavaFX we removed the tiling altogether 
and return one alpha array for the entire rasterization.  We might 
consider doing that for this code as well if it allows us to get rid of 
Ductus - it was a Ductus design constraint that forced the tiling (it 
was again based on the expected size of the hardware AA engine)...

			...jim

On 4/23/13 2:58 PM, Laurent Bourg?s wrote:
> Jim,
>
> I am preparing an updated patch that will contain less syntax changes
> and boiler plates. Sorry again.
>
> I have optimized few array cleaning and it perform as fast as ductus on
> the biggest map test : in average equals !!
>
> i will send results and comparisons tomorrow.
>
> Hint: alpha array cleaning in renderer endRendering can be optimized by
> filling only dirty part as i already do in the given patch. This small
> change can be applied easily...
>
> Le 22 avr. 2013 23:05, "Jim Graham"  > a ?crit :
>>
>> One thing about modifying the iterators.  I originally commented that I thought an object there was a bit much but it helped Denis, who was doing all the work after all, keep the code organized in his mind.  I'm not sure what kind of measurements he made, but he didn't feel that they were hurting performance at the time.  If you are finding that the allocation of the iterators is costing us then I'd just as much like to see that paradigm go away, though your fix to allocate them once and then re-init them does save the memory costs.
>>
>> Other renderers I've worked on an written have done essentially the same work inline rather than farming it out to another object.
>>
>> I also think it's a good suggestion to keep fixes on code like this more focused on isolating the fix itself rather than reorganizing the code to a personal style to fix a few issues.  So, as far as the code organization changes I agree with Clemens there.  When it comes down to "a quick fix that doesn't touch many lines of code" like your init() solution vs. "rewriting that part of the code to no longer need the operations that were causing problems" then it gets grayer.  I would have probably eliminated the iterators altogether because I would view it as reducing the complexity of the code, but your solution would probably touch fewer lines of code (if you factor out the reorganization).  I at least wanted to throw that idea out as a suggestion..
>
> Agreed. I will try to provide smaller changes but it is difficult to
> isolate efficient changes.
>
> Last idea: I think reusing arrays is efficient because they reside in
> the cpu cache... and less gc.
>
> I would like to try perform the rendering / cache / tile generation by
> chunks corresponding to 32 scan lines to have / reuse a smaller rowAARLE
> array...
>
> Finally I looked a bit at clipping shapes and I think it should be done
> first in the Stroker segment processing.
>
> Regards,
> Laurent
>
>>
>>                         ...jim
>>
>>
>> On 4/17/13 9:52 PM, Laurent Bourg?s wrote:
>>>
>>> Hi clemens
>>>
>>> Le 17 avr. 2013 23:16, "Clemens Eisserer" 
>>> >> a ?crit :
>>>
>>>>
>>>> Hi Laurent,
>>>>
>>>>> thanks for having some interest for my efforts !
>>>>> As I got almost no feedback, I felt quite disappointed and was thinking that improving pisces was not important ...
>>>>
>>>>
>>>>
>>>> Glad to see work is ongoing to improve pisces's performance :)
>>>>
>>>
>>> Thanks a lot: I am working on pisces during my spare time and
>>> congratulations is very important for my motivation.
>>>
>>>> I had a look at the patch just to be curious (I don't have reviewer status), but to be honest I had troubles finding the relevant parts.
>>>
>>>
>>> I agree I modify the code to help me understanding it : @override,
>>> grouped fields, constant first, debug logs ...
>>>
>>> I can revert most of these boilerplates ... during cleanup.
>>>
>>> I sent the patch as webrev to let other people evaluate its performance
>>> using their own platform, work load, benchmarks ...
>>>
>>>> Having not followed the discussion that closely, it was almost impossible for me to extract the real modifications from boilerplate/refactoring as your patch weights almost 3000 modified lines.
>>>
>>>
>>> I looked at the webrev and I advocate I can discard many line changes.
>>> As I use netbeans, it modified the code so easily... nevermind.
>>>
>>>> I am just an intrested observer without any official state, yet personally I would prefer smaller pieces with clear description/title.
>>>> However, I wouldn't want to cause you additional work and it's just a single opinion.
>>>>
>>>
>>> Ok. I mainly modified memory handling: use a renderer cache to reuse
>>> arrays and pisces class instances to avoid too much allocations and
>>> resizing ... stored in thread local or concurrent queue.
>>>
>>>> Thanks for working on pisces!
>>>
>>>
>>> Thanks for your feedback too.
>>>
>>> Laurent
>>>
>>>>
>>>> Regards, Clemens
>>>>
>>>>
>>>
>


From lana.steuck at oracle.com  Wed Apr 24 03:51:39 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 24 Apr 2013 03:51:39 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d: 9 new changesets
Message-ID: <20130424035140.EA6B948556@hg.openjdk.java.net>

Changeset: bee6ff988f9c
Author:    katleman
Date:      2013-04-12 15:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/bee6ff988f9c

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! common/autoconf/compare.sh.in
! common/bin/compare.sh

Changeset: 8c5b18d6f4fb
Author:    katleman
Date:      2013-04-15 14:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/8c5b18d6f4fb

Merge


Changeset: df9b5240f0a7
Author:    katleman
Date:      2013-04-16 14:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/df9b5240f0a7

Merge


Changeset: 6981694f7674
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/6981694f7674

Added tag jdk8-b86 for changeset df9b5240f0a7

! .hgtags

Changeset: 7da551071fe8
Author:    lana
Date:      2013-04-11 19:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/7da551071fe8

Merge

! common/makefiles/Main.gmk

Changeset: b95c5c8ee60a
Author:    jgish
Date:      2013-04-16 13:25 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/b95c5c8ee60a

8011347: JKD-8009824 has broken webrev with some ksh versions
Reviewed-by: mduigou

! make/scripts/webrev.ksh

Changeset: 2600c8d8b619
Author:    lana
Date:      2013-04-17 10:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/2600c8d8b619

Merge


Changeset: 238b28991d66
Author:    lana
Date:      2013-04-17 21:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/238b28991d66

Merge


Changeset: b9415faa7066
Author:    lana
Date:      2013-04-23 09:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/rev/b9415faa7066

Merge




From lana.steuck at oracle.com  Wed Apr 24 03:51:38 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 24 Apr 2013 03:51:38 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/corba: Added tag jdk8-b86 for
	changeset 44a8ce4a759f
Message-ID: <20130424035143.C8D1F48557@hg.openjdk.java.net>

Changeset: f1709874d55a
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/corba/rev/f1709874d55a

Added tag jdk8-b86 for changeset 44a8ce4a759f

! .hgtags



From lana.steuck at oracle.com  Wed Apr 24 03:51:47 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 24 Apr 2013 03:51:47 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/nashorn: 18 new changesets
Message-ID: <20130424035205.D66F248559@hg.openjdk.java.net>

Changeset: e7e82c1e9aed
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/e7e82c1e9aed

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! docs/JavaScriptingProgrammersGuide.html
! src/jdk/nashorn/api/scripting/Formatter.java

Changeset: 399a4b8e4607
Author:    katleman
Date:      2013-04-15 14:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/399a4b8e4607

Merge


Changeset: 002ad9d6735f
Author:    katleman
Date:      2013-04-16 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/002ad9d6735f

Merge


Changeset: 899cbeee7253
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/899cbeee7253

Added tag jdk8-b86 for changeset 002ad9d6735f

! .hgtags

Changeset: 480b90430d29
Author:    lana
Date:      2013-04-11 19:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/480b90430d29

Merge


Changeset: 635a93b61d34
Author:    hannesw
Date:      2013-04-10 14:00 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/635a93b61d34

8011714: Regexp decimal escape handling still not correct
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8011714.js
+ test/script/basic/JDK-8011714.js.EXPECTED

Changeset: b4ea8678bf15
Author:    hannesw
Date:      2013-04-10 14:05 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/b4ea8678bf15

8011749: Bugs with empty character class handling
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8011749.js
+ test/script/basic/JDK-8011749.js.EXPECTED

Changeset: 8ae9ed1ac1e2
Author:    hannesw
Date:      2013-04-10 14:08 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/8ae9ed1ac1e2

8011756: Wrong characters supported in RegExp \c escape
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8011756.js
+ test/script/basic/JDK-8011756.js.EXPECTED

Changeset: 571e06d5d23c
Author:    sundar
Date:      2013-04-11 13:20 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/571e06d5d23c

8011960: [2,1].sort(null) should throw TypeError
Reviewed-by: hannesw, lagergren

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8011960.js

Changeset: 256bb030ce0a
Author:    sundar
Date:      2013-04-11 15:04 +0530
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/256bb030ce0a

8011974: Comparator function returning negative and positive Infinity does not work as expected with Array.prototype.sort
Reviewed-by: hannesw, lagergren

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8011974.js

Changeset: a3fc89d33072
Author:    hannesw
Date:      2013-04-11 12:16 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/a3fc89d33072

8011980: Allow NUL character in character class
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8011980.js
+ test/script/basic/JDK-8011980.js.EXPECTED

Changeset: ed4293ceec0e
Author:    hannesw
Date:      2013-04-12 16:31 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/ed4293ceec0e

8011884: Regexp literals are compiled twice
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java

Changeset: 36e36a2d4312
Author:    hannesw
Date:      2013-04-12 16:32 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/36e36a2d4312

8011885: Switch to Joni as default Regexp engine
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java

Changeset: e70e6b38826b
Author:    jlaskey
Date:      2013-04-15 08:39 -0300
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/e70e6b38826b

Merge


Changeset: 222a72df2f42
Author:    mchung
Date:      2013-04-16 22:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/222a72df2f42

8010117: Annotate jdk caller sensitive methods with @sun.reflect.CallerSensitive
Reviewed-by: jrose, alanb, twisti, sundar

! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java
! src/jdk/nashorn/internal/runtime/Context.java

Changeset: 44d8612e29b0
Author:    lana
Date:      2013-04-17 10:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/44d8612e29b0

Merge


Changeset: cba329ce5efe
Author:    lana
Date:      2013-04-17 21:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/cba329ce5efe

Merge


Changeset: 774aeaa89bc1
Author:    lana
Date:      2013-04-23 09:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/nashorn/rev/774aeaa89bc1

Merge




From lana.steuck at oracle.com  Wed Apr 24 03:51:52 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 24 Apr 2013 03:51:52 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jaxp: 4 new changesets
Message-ID: <20130424035207.ABBA54855A@hg.openjdk.java.net>

Changeset: 9550aab82b5d
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/9550aab82b5d

Added tag jdk8-b86 for changeset ca71ec37b2ef

! .hgtags

Changeset: 10db50a26b39
Author:    joehw
Date:      2013-02-18 11:33 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/10db50a26b39

6657673: Issues with JAXP
Reviewed-by: alanb, lancea, ahgross, mullan

! src/com/sun/org/apache/bcel/internal/classfile/JavaClass.java
! src/com/sun/org/apache/bcel/internal/util/Class2HTML.java
! src/com/sun/org/apache/bcel/internal/util/ClassPath.java
! src/com/sun/org/apache/bcel/internal/util/JavaWrapper.java
+ src/com/sun/org/apache/bcel/internal/util/SecuritySupport.java
! src/com/sun/org/apache/xalan/internal/res/XSLMessages.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java
! src/com/sun/org/apache/xalan/internal/utils/ObjectFactory.java
! src/com/sun/org/apache/xalan/internal/utils/SecuritySupport.java
! src/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
! src/com/sun/org/apache/xalan/internal/xslt/Process.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMsg.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Util.java
! src/com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecord.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/output/WriterOutputBuffer.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java
! src/com/sun/org/apache/xerces/internal/dom/DOMMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
! src/com/sun/org/apache/xerces/internal/impl/dv/DatatypeException.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_de.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_es.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_fr.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_it.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ja.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ko.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_pt_BR.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_sv.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_CN.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_TW.java
! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegexParser.java
! src/com/sun/org/apache/xerces/internal/impl/xs/XSMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/JAXPValidationMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/util/DatatypeMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/util/SAXMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/util/SecurityManager.java
! src/com/sun/org/apache/xerces/internal/utils/ObjectFactory.java
! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java
! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/xpointer/XPointerMessageFormatter.java
! src/com/sun/org/apache/xml/internal/dtm/DTMManager.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ca.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_cs.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_de.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_fr.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_it.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ja.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_pt_BR.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sk.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_tr.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java
! src/com/sun/org/apache/xml/internal/res/XMLMessages.java
! src/com/sun/org/apache/xml/internal/resolver/Catalog.java
! src/com/sun/org/apache/xml/internal/resolver/CatalogManager.java
! src/com/sun/org/apache/xml/internal/resolver/Resolver.java
! src/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java
! src/com/sun/org/apache/xml/internal/serializer/Encodings.java
! src/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java
! src/com/sun/org/apache/xml/internal/serializer/ToStream.java
! src/com/sun/org/apache/xml/internal/serializer/TreeWalker.java
! src/com/sun/org/apache/xml/internal/serializer/utils/Messages.java
! src/com/sun/org/apache/xml/internal/utils/TreeWalker.java
! src/com/sun/org/apache/xml/internal/utils/res/XResourceBundle.java
! src/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_de.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_fr.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_it.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ko.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_pt_BR.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_sv.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_CN.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_TW.java
! src/com/sun/org/apache/xpath/internal/res/XPATHMessages.java
! src/com/sun/xml/internal/stream/XMLEntityStorage.java
! src/com/sun/xml/internal/stream/writers/WriterUtility.java
! src/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java
! src/javax/xml/datatype/FactoryFinder.java
! src/javax/xml/parsers/FactoryFinder.java
! src/javax/xml/stream/FactoryFinder.java
! src/javax/xml/transform/FactoryFinder.java
! src/javax/xml/validation/SchemaFactoryFinder.java
! src/javax/xml/xpath/XPathFactoryFinder.java
! src/org/w3c/dom/bootstrap/DOMImplementationRegistry.java
! src/org/xml/sax/helpers/NewInstance.java
! src/org/xml/sax/helpers/ParserAdapter.java
! src/org/xml/sax/helpers/ParserFactory.java
+ src/org/xml/sax/helpers/SecuritySupport.java
! src/org/xml/sax/helpers/XMLReaderFactory.java

Changeset: 3f9817b8b0e0
Author:    chegar
Date:      2013-04-12 10:20 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/3f9817b8b0e0

Merge


Changeset: eddbc8ad2435
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxp/rev/eddbc8ad2435

Merge




From lana.steuck at oracle.com  Wed Apr 24 03:51:43 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 24 Apr 2013 03:51:43 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jaxws: 4 new changesets
Message-ID: <20130424035159.5D1C148558@hg.openjdk.java.net>

Changeset: 8abe95530f58
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxws/rev/8abe95530f58

Added tag jdk8-b86 for changeset a5e7c2f093c9

! .hgtags

Changeset: 28886cb008bb
Author:    lana
Date:      2013-04-11 19:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxws/rev/28886cb008bb

Merge


Changeset: ebbd87e3a8b2
Author:    lana
Date:      2013-04-17 10:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxws/rev/ebbd87e3a8b2

Merge


Changeset: 9d251e1ec1eb
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jaxws/rev/9d251e1ec1eb

Merge




From lana.steuck at oracle.com  Wed Apr 24 03:51:49 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 24 Apr 2013 03:51:49 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/hotspot: 9 new changesets
Message-ID: <20130424035216.386C84855B@hg.openjdk.java.net>

Changeset: b0301c02f38e
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/b0301c02f38e

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! make/bsd/makefiles/fastdebug.make
! src/share/vm/services/diagnosticArgument.cpp
! test/sanity/WBApi.java
! test/serviceability/ParserTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java
! test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java

Changeset: c9eb0ec1c792
Author:    katleman
Date:      2013-04-15 14:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/c9eb0ec1c792

Merge

! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 86db4847f195
Author:    katleman
Date:      2013-04-17 12:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/86db4847f195

Merge

! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 2e657354f6bc
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/2e657354f6bc

Added tag jdk8-b86 for changeset 86db4847f195

! .hgtags

Changeset: 3d641132f83b
Author:    twisti
Date:      2013-02-26 16:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/3d641132f83b

8004336: Better handling of method handle intrinsic frames
Reviewed-by: kvn, jrose, ahgross

! src/share/vm/opto/library_call.cpp

Changeset: 124ca22437b1
Author:    chegar
Date:      2013-04-12 10:14 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/124ca22437b1

Merge

! src/share/vm/opto/library_call.cpp

Changeset: 6c560f9ebb3e
Author:    lana
Date:      2013-04-17 10:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/6c560f9ebb3e

Merge

- test/gc/6941923/test6941923.sh
- test/gc/TestVerifyBeforeGCDuringStartup.java

Changeset: db9c527a1fd8
Author:    lana
Date:      2013-04-17 21:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/db9c527a1fd8

Merge


Changeset: d4c266784660
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/hotspot/rev/d4c266784660

Merge




From lana.steuck at oracle.com  Wed Apr 24 03:51:49 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 24 Apr 2013 03:51:49 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/langtools: 20 new changesets
Message-ID: <20130424035253.A1B7A4855C@hg.openjdk.java.net>

Changeset: 2b585be0da7a
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/2b585be0da7a

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! test/com/sun/javadoc/testAnnotationOptional/TestAnnotationOptional.java
! test/com/sun/javadoc/testAnnotationOptional/pkg/AnnotationOptional.java
! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java
! test/com/sun/javadoc/typeAnnotations/smoke/pkg/TargetTypes.java

Changeset: 717bcda533f2
Author:    katleman
Date:      2013-04-15 14:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/717bcda533f2

Merge


Changeset: 6ab578e141df
Author:    katleman
Date:      2013-04-16 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/6ab578e141df

Merge


Changeset: 4f4509c2fe35
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/4f4509c2fe35

Added tag jdk8-b86 for changeset 6ab578e141df

! .hgtags

Changeset: eb134c8e931d
Author:    bpatel
Date:      2013-04-09 14:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/eb134c8e931d

8005091: javadoc should be able to return the receiver type
Reviewed-by: jjg

! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java
! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
+ test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/ClassExtends.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/ClassParameters.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Fields.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/MethodReturnType.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/MethodTypeParameters.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Parameters.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Receivers.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Throws.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/TypeParameters.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Varargs.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Wildcards.java

Changeset: a4be2c2fe0a1
Author:    vromero
Date:      2013-04-10 12:31 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/a4be2c2fe0a1

8011432: javac, compiler regression iterable + captured type
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
! test/tools/javac/T5053846/MethodRefDupInConstantPoolTest.java

Changeset: d13af7751456
Author:    lana
Date:      2013-04-11 19:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/d13af7751456

Merge


Changeset: 137994c189e5
Author:    jfranck
Date:      2013-04-12 12:05 +0200
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/137994c189e5

7015104: use new subtype of TypeSymbol for type parameters
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/scope/7017664/CompoundScopeTest.java
! test/tools/javac/types/TypeHarness.java

Changeset: 76537856a54e
Author:    vromero
Date:      2013-04-13 12:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/76537856a54e

8010659: Javac Crashes while building OpenJFX
Reviewed-by: jjg
Contributed-by: maurizio.cimadamore at oracle.com

+ src/share/classes/com/sun/tools/javac/comp/CompileStates.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
+ test/tools/javac/T8010659/CompilerCrashWhenMixingBinariesAndSourcesTest.java
! test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java
! test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java

Changeset: f10cffab99b4
Author:    bpatel
Date:      2013-04-13 18:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/f10cffab99b4

8009686: Generated javadoc documentation should be able to display type annotation on an array
Reviewed-by: jjg

! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java
! src/share/classes/com/sun/javadoc/Type.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java
! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java
! test/com/sun/javadoc/testTypeAnnotations/typeannos/Fields.java

Changeset: b26f36a7ae3b
Author:    mcimadamore
Date:      2013-04-15 14:11 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/b26f36a7ae3b

8011383: Symbol.getModifiers omits ACC_ABSTRACT from interface with default methods
Summary: Fixup for default method modifiers erroneously applies to class-level modifiers
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ test/tools/javac/defaultMethods/DefaultMethodFlags.java

Changeset: c430f1cde21c
Author:    mcimadamore
Date:      2013-04-15 14:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/c430f1cde21c

8011377: Javac crashes when multiple lambdas are defined in an array
Summary: Wrong attribution environment used by DeferredAttr
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Flow.java
+ test/tools/javac/lambda/TargetType71.java

Changeset: 083c6b199e2f
Author:    mcimadamore
Date:      2013-04-15 14:15 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/083c6b199e2f

8011376: Spurious checked exception errors in nested method call
Summary: Fallback attribution logic doesn't work properly when lambda throws checked exceptions
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/lambda/TargetType72.java

Changeset: 6dacab087652
Author:    mcimadamore
Date:      2013-04-15 14:16 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/6dacab087652

8011028: lang/INFR/infr001/infr00101md/infr00101md.java fails to compile after switch to JDK8-b82
Summary: Fix bug in Types.removeWildcards
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! test/tools/javac/lambda/TargetType69.java
+ test/tools/javac/lambda/TargetType70.java

Changeset: c2315af9cc28
Author:    mcimadamore
Date:      2013-04-15 14:17 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/c2315af9cc28

8011392: Missing checkcast when casting to intersection type
Summary: javac should emit a checkcast for each additional target type specified in an intersection type cast
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/tools/javac/lambda/Intersection03.java

Changeset: 950e8ac120f0
Author:    mcimadamore
Date:      2013-04-15 14:18 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/950e8ac120f0

8010923: Avoid redundant speculative attribution
Summary: Add optimization to avoid speculative attribution for certain argument expressions
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java

Changeset: 49d32c84dfea
Author:    vromero
Date:      2013-04-17 11:11 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/49d32c84dfea

8011181: javac, empty UTF8 entry generated for inner class
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
+ test/tools/javac/T8011181/EmptyUTF8ForInnerClassNameTest.java

Changeset: 94870c08391c
Author:    lana
Date:      2013-04-17 10:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/94870c08391c

Merge


Changeset: cad4fc23f691
Author:    lana
Date:      2013-04-17 21:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/cad4fc23f691

Merge


Changeset: 1329f9c38d93
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/langtools/rev/1329f9c38d93

Merge




From lana.steuck at oracle.com  Wed Apr 24 03:54:18 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 24 Apr 2013 03:54:18 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 100 new changesets
Message-ID: <20130424041405.DDD964855D@hg.openjdk.java.net>

Changeset: e5c5e369af6a
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e5c5e369af6a

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
! src/share/classes/java/util/function/DoublePredicate.java
! src/share/classes/java/util/function/IntPredicate.java
! src/share/classes/java/util/function/LongPredicate.java
! src/share/classes/java/util/function/ObjIntConsumer.java
! src/share/classes/java/util/function/ToDoubleBiFunction.java
! test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh
! test/java/lang/reflect/Method/IsDefaultTest.java
! test/java/net/URLConnection/RequestProperties.java
! test/java/util/Optional/BasicDouble.java
! test/javax/swing/text/html/7189299/bug7189299.java
! test/sun/management/jdp/JdpTest.sh
! test/sun/misc/URLClassPath/JarLoaderTest.java
! test/sun/util/calendar/zi/ZoneInfoFile.java

Changeset: b45456703c65
Author:    katleman
Date:      2013-04-15 14:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b45456703c65

Merge


Changeset: 7989cd0cc3a9
Author:    katleman
Date:      2013-04-16 15:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7989cd0cc3a9

Merge


Changeset: f4c62eecf7fa
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f4c62eecf7fa

Added tag jdk8-b86 for changeset 7989cd0cc3a9

! .hgtags

Changeset: 0799af4553b5
Author:    lana
Date:      2013-04-17 21:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0799af4553b5

Merge

- src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM

Changeset: d241f117ff46
Author:    malenkov
Date:      2013-04-11 19:12 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d241f117ff46

4683761: Incomplete Introspection on nonpublic classes lead to IllegalAccessExceptions
Reviewed-by: alexsch

! src/share/classes/java/beans/Introspector.java
+ test/java/beans/Introspector/Test4683761.java

Changeset: be89273ceb9c
Author:    pchelko
Date:      2013-04-12 14:09 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/be89273ceb9c

8010009: [macosx] Unable type into online word games on MacOSX
Reviewed-by: anthony, dcherepanov

! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
+ test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.html
+ test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.java
+ test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/TestApplet.java

Changeset: 4490ef60ecd3
Author:    anthony
Date:      2013-04-12 14:33 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4490ef60ecd3

8010297: Missing isLoggable() checks in logging code
Summary: Add isLoggable() checks
Reviewed-by: anthony, mchung, serb
Contributed-by: Laurent Bourges 

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java
! src/share/classes/java/awt/DefaultKeyboardFocusManager.java
! src/share/classes/java/awt/EventDispatchThread.java
! src/share/classes/java/awt/KeyboardFocusManager.java
! src/share/classes/java/awt/WaitDispatchSupport.java
! src/share/classes/javax/swing/BufferStrategyPaintManager.java
! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java
! src/share/classes/sun/awt/AWTAutoShutdown.java
! src/share/classes/sun/awt/DebugSettings.java
! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java
! src/share/classes/sun/awt/SunToolkit.java
! src/share/classes/sun/awt/im/InputContext.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java
! src/share/classes/sun/net/www/protocol/http/Negotiator.java
! src/solaris/classes/sun/awt/X11/XAWTXSettings.java
! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java
! src/solaris/classes/sun/awt/X11/XBaseWindow.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/awt/X11/XContentWindow.java
! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java
! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java
! src/solaris/classes/sun/awt/X11/XFramePeer.java
! src/solaris/classes/sun/awt/X11/XIconWindow.java
! src/solaris/classes/sun/awt/X11/XInputMethod.java
! src/solaris/classes/sun/awt/X11/XListPeer.java
! src/solaris/classes/sun/awt/X11/XMSelection.java
! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java
! src/solaris/classes/sun/awt/X11/XMenuPeer.java
! src/solaris/classes/sun/awt/X11/XNETProtocol.java
! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java
! src/solaris/classes/sun/awt/X11/XProtocol.java
! src/solaris/classes/sun/awt/X11/XScrollbar.java
! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java
! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java
! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java
! src/solaris/classes/sun/awt/X11/XWINProtocol.java
! src/solaris/classes/sun/awt/X11/XWM.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java
! src/solaris/classes/sun/awt/X11InputMethod.java
! src/windows/classes/sun/awt/windows/WComponentPeer.java

Changeset: 39ce1056694d
Author:    serb
Date:      2013-04-12 15:28 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/39ce1056694d

8000629: [macosx] Blurry rendering with Java 7 on Retina display
Reviewed-by: anthony, prr, flar

! src/macosx/classes/sun/awt/CGraphicsDevice.java
! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/macosx/classes/sun/java2d/opengl/CGLLayer.java
! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java
! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/CGraphicsDevice.m
! src/macosx/native/sun/java2d/opengl/CGLLayer.m
! src/share/classes/sun/awt/image/SurfaceManager.java
! src/share/classes/sun/java2d/SunGraphics2D.java
! src/share/classes/sun/java2d/SurfaceData.java
! src/share/classes/sun/java2d/pipe/BufferedContext.java
! src/share/classes/sun/java2d/pipe/DrawImage.java
! src/share/classes/sun/java2d/pipe/Region.java
+ test/java/awt/Graphics2D/FillTexturePaint/FillTexturePaint.java
+ test/java/awt/Graphics2D/FlipDrawImage/FlipDrawImage.java
+ test/java/awt/Graphics2D/TransformSetGet/TransformSetGet.java
+ test/java/awt/image/DrawImage/IncorrectBounds.java
+ test/java/awt/image/DrawImage/IncorrectOffset.java

Changeset: ffd45b1a9c11
Author:    serb
Date:      2013-04-12 20:39 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ffd45b1a9c11

8004866: [macosx] HiDPI support in Aqua L&F
Reviewed-by: swingler, alexsch

! src/macosx/classes/com/apple/laf/AquaPainter.java
! src/macosx/classes/com/apple/laf/ImageCache.java
! src/macosx/native/com/apple/laf/JRSUIController.m

Changeset: dcdf8cd4b09e
Author:    ant
Date:      2013-04-15 13:02 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/dcdf8cd4b09e

7147075: JTextField doesn't get focus or loses focus forever
Reviewed-by: anthony

! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java

Changeset: 8fbe247ad2d8
Author:    lana
Date:      2013-04-17 11:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/8fbe247ad2d8

Merge

! src/share/classes/sun/java2d/SunGraphics2D.java
! src/share/classes/sun/java2d/pipe/BufferedContext.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java

Changeset: bb098a221d85
Author:    lana
Date:      2013-04-17 21:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/bb098a221d85

Merge


Changeset: 863da64214e8
Author:    mduigou
Date:      2013-04-10 14:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/863da64214e8

8010948: Add conversion functional interfaces
Reviewed-by: mduigou, dholmes
Contributed-by: Brian Goetz 

+ src/share/classes/java/util/function/DoubleToIntFunction.java
+ src/share/classes/java/util/function/DoubleToLongFunction.java
+ src/share/classes/java/util/function/IntToDoubleFunction.java
+ src/share/classes/java/util/function/IntToLongFunction.java
+ src/share/classes/java/util/function/LongToDoubleFunction.java
+ src/share/classes/java/util/function/LongToIntFunction.java

Changeset: b0458dd21ba6
Author:    darcy
Date:      2013-04-10 16:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b0458dd21ba6

8011930: Long.parseLong(String, int) has inaccurate limit on radix for using 'L'
Reviewed-by: smarks

! src/share/classes/java/lang/Long.java

Changeset: 6f8e1428f7c3
Author:    weijun
Date:      2013-04-11 10:58 +0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6f8e1428f7c3

8005460: [findbugs] Probably returned array should be cloned
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/PrincipalName.java
+ test/sun/security/krb5/name/Immutable.java

Changeset: 0ab22e58d151
Author:    weijun
Date:      2013-04-11 11:09 +0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0ab22e58d151

8011867: Accept unknown PKCS #9 attributes
Reviewed-by: vinnie

! src/share/classes/sun/security/pkcs/PKCS9Attribute.java
+ test/sun/security/pkcs/pkcs9/UnknownAttribute.java

Changeset: 1c3fff140324
Author:    weijun
Date:      2013-04-11 11:10 +0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/1c3fff140324

8011745: Unknown CertificateChoices
Reviewed-by: vinnie

! src/share/classes/sun/security/pkcs/PKCS7.java

Changeset: 006a7a576fe9
Author:    peytoia
Date:      2013-04-11 12:22 +0900
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/006a7a576fe9

8009638: Wrong comment for PL in LocaleISOData, 1989 forward Poland is Republic of Poland
Reviewed-by: okutsu

! src/share/classes/java/util/LocaleISOData.java

Changeset: e62a707a77d8
Author:    lana
Date:      2013-04-11 19:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e62a707a77d8

Merge


Changeset: f4d50e8cc9e2
Author:    sherman
Date:      2013-04-12 07:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f4d50e8cc9e2

8011172: JSR 310 DateTime API Updates II
Summary: Integration of JSR310 Date/Time API update
Reviewed-by: alanb, naoto, dholmes
Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com

! make/java/java/Makefile
! make/java/text/base/FILES_java.gmk
! make/java/util/FILES_java.gmk
! make/sun/text/FILES_java.gmk
! make/sun/tzdb/Makefile
! make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java
! make/tools/src/build/tools/cldrconverter/Bundle.java
! make/tools/src/build/tools/cldrconverter/CLDRConverter.java
! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java
! make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java
! makefiles/CopyFiles.gmk
! makefiles/CreateJars.gmk
! makefiles/GendataTZDB.gmk
! makefiles/profile-includes.txt
! src/share/classes/java/time/DayOfWeek.java
! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/Month.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZoneRegion.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoDateImpl.java
! src/share/classes/java/time/chrono/ChronoLocalDate.java
! src/share/classes/java/time/chrono/ChronoLocalDateTime.java
! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/share/classes/java/time/chrono/ChronoZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/Era.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/HijrahDate.java
- src/share/classes/java/time/chrono/HijrahDeviationReader.java
! src/share/classes/java/time/chrono/HijrahEra.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/chrono/IsoEra.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/JapaneseEra.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/MinguoEra.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistEra.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! src/share/classes/java/time/format/DateTimeParseContext.java
! src/share/classes/java/time/format/DateTimePrintContext.java
! src/share/classes/java/time/format/DateTimeTextProvider.java
+ src/share/classes/java/time/format/Parsed.java
+ src/share/classes/java/time/format/ResolverStyle.java
! src/share/classes/java/time/format/TextStyle.java
- src/share/classes/java/time/temporal/Adjusters.java
! src/share/classes/java/time/temporal/ChronoField.java
! src/share/classes/java/time/temporal/ChronoUnit.java
! src/share/classes/java/time/temporal/IsoFields.java
! src/share/classes/java/time/temporal/JulianFields.java
- src/share/classes/java/time/temporal/Queries.java
! src/share/classes/java/time/temporal/Temporal.java
! src/share/classes/java/time/temporal/TemporalAccessor.java
! src/share/classes/java/time/temporal/TemporalAdjuster.java
+ src/share/classes/java/time/temporal/TemporalAdjusters.java
! src/share/classes/java/time/temporal/TemporalAmount.java
! src/share/classes/java/time/temporal/TemporalField.java
+ src/share/classes/java/time/temporal/TemporalQueries.java
! src/share/classes/java/time/temporal/TemporalQuery.java
! src/share/classes/java/time/temporal/TemporalUnit.java
+ src/share/classes/java/time/temporal/UnsupportedTemporalTypeException.java
! src/share/classes/java/time/temporal/ValueRange.java
! src/share/classes/java/time/temporal/WeekFields.java
! src/share/classes/java/time/temporal/package-info.java
! src/share/classes/java/time/zone/TzdbZoneRulesProvider.java
! src/share/classes/java/time/zone/ZoneOffsetTransition.java
! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java
! src/share/classes/java/time/zone/ZoneRulesProvider.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/sun/text/resources/FormatData.java
+ src/share/classes/sun/text/resources/JavaTimeSupplementary.java
! src/share/classes/sun/text/resources/ar/FormatData_ar.java
! src/share/classes/sun/text/resources/ar/FormatData_ar_JO.java
! src/share/classes/sun/text/resources/ar/FormatData_ar_LB.java
! src/share/classes/sun/text/resources/ar/FormatData_ar_SY.java
+ src/share/classes/sun/text/resources/ar/JavaTimeSupplementary_ar.java
! src/share/classes/sun/text/resources/be/FormatData_be.java
! src/share/classes/sun/text/resources/be/FormatData_be_BY.java
+ src/share/classes/sun/text/resources/be/JavaTimeSupplementary_be.java
! src/share/classes/sun/text/resources/bg/FormatData_bg.java
! src/share/classes/sun/text/resources/bg/FormatData_bg_BG.java
+ src/share/classes/sun/text/resources/bg/JavaTimeSupplementary_bg.java
! src/share/classes/sun/text/resources/ca/FormatData_ca.java
! src/share/classes/sun/text/resources/ca/FormatData_ca_ES.java
+ src/share/classes/sun/text/resources/ca/JavaTimeSupplementary_ca.java
! src/share/classes/sun/text/resources/cs/FormatData_cs.java
! src/share/classes/sun/text/resources/cs/FormatData_cs_CZ.java
+ src/share/classes/sun/text/resources/cs/JavaTimeSupplementary_cs.java
! src/share/classes/sun/text/resources/da/FormatData_da.java
! src/share/classes/sun/text/resources/da/FormatData_da_DK.java
+ src/share/classes/sun/text/resources/da/JavaTimeSupplementary_da.java
! src/share/classes/sun/text/resources/de/FormatData_de.java
! src/share/classes/sun/text/resources/de/FormatData_de_AT.java
! src/share/classes/sun/text/resources/de/FormatData_de_CH.java
! src/share/classes/sun/text/resources/de/FormatData_de_DE.java
! src/share/classes/sun/text/resources/de/FormatData_de_LU.java
+ src/share/classes/sun/text/resources/de/JavaTimeSupplementary_de.java
! src/share/classes/sun/text/resources/el/FormatData_el.java
! src/share/classes/sun/text/resources/el/FormatData_el_CY.java
! src/share/classes/sun/text/resources/el/FormatData_el_GR.java
+ src/share/classes/sun/text/resources/el/JavaTimeSupplementary_el.java
! src/share/classes/sun/text/resources/en/FormatData_en.java
! src/share/classes/sun/text/resources/en/FormatData_en_AU.java
! src/share/classes/sun/text/resources/en/FormatData_en_CA.java
! src/share/classes/sun/text/resources/en/FormatData_en_GB.java
! src/share/classes/sun/text/resources/en/FormatData_en_IE.java
! src/share/classes/sun/text/resources/en/FormatData_en_IN.java
! src/share/classes/sun/text/resources/en/FormatData_en_MT.java
! src/share/classes/sun/text/resources/en/FormatData_en_NZ.java
! src/share/classes/sun/text/resources/en/FormatData_en_PH.java
! src/share/classes/sun/text/resources/en/FormatData_en_SG.java
! src/share/classes/sun/text/resources/en/FormatData_en_US.java
! src/share/classes/sun/text/resources/en/FormatData_en_ZA.java
+ src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en.java
+ src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_GB.java
+ src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_SG.java
! src/share/classes/sun/text/resources/es/FormatData_es.java
! src/share/classes/sun/text/resources/es/FormatData_es_AR.java
! src/share/classes/sun/text/resources/es/FormatData_es_BO.java
! src/share/classes/sun/text/resources/es/FormatData_es_CL.java
! src/share/classes/sun/text/resources/es/FormatData_es_CO.java
! src/share/classes/sun/text/resources/es/FormatData_es_CR.java
! src/share/classes/sun/text/resources/es/FormatData_es_DO.java
! src/share/classes/sun/text/resources/es/FormatData_es_EC.java
! src/share/classes/sun/text/resources/es/FormatData_es_ES.java
! src/share/classes/sun/text/resources/es/FormatData_es_GT.java
! src/share/classes/sun/text/resources/es/FormatData_es_HN.java
! src/share/classes/sun/text/resources/es/FormatData_es_MX.java
! src/share/classes/sun/text/resources/es/FormatData_es_NI.java
! src/share/classes/sun/text/resources/es/FormatData_es_PA.java
! src/share/classes/sun/text/resources/es/FormatData_es_PE.java
! src/share/classes/sun/text/resources/es/FormatData_es_PR.java
! src/share/classes/sun/text/resources/es/FormatData_es_PY.java
! src/share/classes/sun/text/resources/es/FormatData_es_SV.java
! src/share/classes/sun/text/resources/es/FormatData_es_US.java
! src/share/classes/sun/text/resources/es/FormatData_es_UY.java
! src/share/classes/sun/text/resources/es/FormatData_es_VE.java
+ src/share/classes/sun/text/resources/es/JavaTimeSupplementary_es.java
! src/share/classes/sun/text/resources/et/FormatData_et.java
! src/share/classes/sun/text/resources/et/FormatData_et_EE.java
+ src/share/classes/sun/text/resources/et/JavaTimeSupplementary_et.java
! src/share/classes/sun/text/resources/fi/FormatData_fi.java
! src/share/classes/sun/text/resources/fi/FormatData_fi_FI.java
+ src/share/classes/sun/text/resources/fi/JavaTimeSupplementary_fi.java
! src/share/classes/sun/text/resources/fr/FormatData_fr.java
! src/share/classes/sun/text/resources/fr/FormatData_fr_BE.java
! src/share/classes/sun/text/resources/fr/FormatData_fr_CA.java
! src/share/classes/sun/text/resources/fr/FormatData_fr_CH.java
! src/share/classes/sun/text/resources/fr/FormatData_fr_FR.java
+ src/share/classes/sun/text/resources/fr/JavaTimeSupplementary_fr.java
! src/share/classes/sun/text/resources/ga/FormatData_ga.java
! src/share/classes/sun/text/resources/ga/FormatData_ga_IE.java
+ src/share/classes/sun/text/resources/ga/JavaTimeSupplementary_ga.java
! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java
+ src/share/classes/sun/text/resources/hi/JavaTimeSupplementary_hi_IN.java
! src/share/classes/sun/text/resources/hr/FormatData_hr.java
! src/share/classes/sun/text/resources/hr/FormatData_hr_HR.java
+ src/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java
! src/share/classes/sun/text/resources/hu/FormatData_hu.java
! src/share/classes/sun/text/resources/hu/FormatData_hu_HU.java
+ src/share/classes/sun/text/resources/hu/JavaTimeSupplementary_hu.java
! src/share/classes/sun/text/resources/in/FormatData_in.java
! src/share/classes/sun/text/resources/in/FormatData_in_ID.java
! src/share/classes/sun/text/resources/is/FormatData_is.java
! src/share/classes/sun/text/resources/is/FormatData_is_IS.java
+ src/share/classes/sun/text/resources/is/JavaTimeSupplementary_is.java
! src/share/classes/sun/text/resources/it/FormatData_it.java
! src/share/classes/sun/text/resources/it/FormatData_it_CH.java
! src/share/classes/sun/text/resources/it/FormatData_it_IT.java
+ src/share/classes/sun/text/resources/it/JavaTimeSupplementary_it.java
! src/share/classes/sun/text/resources/iw/FormatData_iw.java
! src/share/classes/sun/text/resources/iw/FormatData_iw_IL.java
+ src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw.java
+ src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw_IL.java
! src/share/classes/sun/text/resources/ja/FormatData_ja.java
! src/share/classes/sun/text/resources/ja/FormatData_ja_JP.java
+ src/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java
! src/share/classes/sun/text/resources/ko/FormatData_ko.java
! src/share/classes/sun/text/resources/ko/FormatData_ko_KR.java
+ src/share/classes/sun/text/resources/ko/JavaTimeSupplementary_ko.java
! src/share/classes/sun/text/resources/lt/FormatData_lt.java
! src/share/classes/sun/text/resources/lt/FormatData_lt_LT.java
+ src/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java
! src/share/classes/sun/text/resources/lv/FormatData_lv.java
! src/share/classes/sun/text/resources/lv/FormatData_lv_LV.java
+ src/share/classes/sun/text/resources/lv/JavaTimeSupplementary_lv.java
! src/share/classes/sun/text/resources/mk/FormatData_mk.java
! src/share/classes/sun/text/resources/mk/FormatData_mk_MK.java
+ src/share/classes/sun/text/resources/mk/JavaTimeSupplementary_mk.java
! src/share/classes/sun/text/resources/ms/FormatData_ms.java
! src/share/classes/sun/text/resources/ms/FormatData_ms_MY.java
+ src/share/classes/sun/text/resources/ms/JavaTimeSupplementary_ms.java
! src/share/classes/sun/text/resources/mt/FormatData_mt.java
! src/share/classes/sun/text/resources/mt/FormatData_mt_MT.java
+ src/share/classes/sun/text/resources/mt/JavaTimeSupplementary_mt.java
! src/share/classes/sun/text/resources/nl/FormatData_nl.java
! src/share/classes/sun/text/resources/nl/FormatData_nl_BE.java
! src/share/classes/sun/text/resources/nl/FormatData_nl_NL.java
+ src/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java
! src/share/classes/sun/text/resources/no/FormatData_no.java
! src/share/classes/sun/text/resources/no/FormatData_no_NO.java
! src/share/classes/sun/text/resources/no/FormatData_no_NO_NY.java
+ src/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java
! src/share/classes/sun/text/resources/pl/FormatData_pl.java
! src/share/classes/sun/text/resources/pl/FormatData_pl_PL.java
+ src/share/classes/sun/text/resources/pl/JavaTimeSupplementary_pl.java
! src/share/classes/sun/text/resources/pt/FormatData_pt.java
! src/share/classes/sun/text/resources/pt/FormatData_pt_BR.java
! src/share/classes/sun/text/resources/pt/FormatData_pt_PT.java
+ src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt.java
+ src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt_PT.java
! src/share/classes/sun/text/resources/ro/FormatData_ro.java
! src/share/classes/sun/text/resources/ro/FormatData_ro_RO.java
+ src/share/classes/sun/text/resources/ro/JavaTimeSupplementary_ro.java
! src/share/classes/sun/text/resources/ru/FormatData_ru.java
! src/share/classes/sun/text/resources/ru/FormatData_ru_RU.java
+ src/share/classes/sun/text/resources/ru/JavaTimeSupplementary_ru.java
! src/share/classes/sun/text/resources/sk/FormatData_sk.java
! src/share/classes/sun/text/resources/sk/FormatData_sk_SK.java
+ src/share/classes/sun/text/resources/sk/JavaTimeSupplementary_sk.java
! src/share/classes/sun/text/resources/sl/FormatData_sl.java
! src/share/classes/sun/text/resources/sl/FormatData_sl_SI.java
+ src/share/classes/sun/text/resources/sl/JavaTimeSupplementary_sl.java
! src/share/classes/sun/text/resources/sq/FormatData_sq.java
! src/share/classes/sun/text/resources/sq/FormatData_sq_AL.java
+ src/share/classes/sun/text/resources/sq/JavaTimeSupplementary_sq.java
! src/share/classes/sun/text/resources/sr/FormatData_sr.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_BA.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_CS.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_Latn_ME.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_ME.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_RS.java
+ src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr.java
+ src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java
! src/share/classes/sun/text/resources/sv/FormatData_sv.java
! src/share/classes/sun/text/resources/sv/FormatData_sv_SE.java
+ src/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java
! src/share/classes/sun/text/resources/th/FormatData_th.java
! src/share/classes/sun/text/resources/th/FormatData_th_TH.java
+ src/share/classes/sun/text/resources/th/JavaTimeSupplementary_th.java
! src/share/classes/sun/text/resources/tr/FormatData_tr.java
! src/share/classes/sun/text/resources/tr/FormatData_tr_TR.java
+ src/share/classes/sun/text/resources/tr/JavaTimeSupplementary_tr.java
! src/share/classes/sun/text/resources/uk/FormatData_uk.java
! src/share/classes/sun/text/resources/uk/FormatData_uk_UA.java
+ src/share/classes/sun/text/resources/uk/JavaTimeSupplementary_uk.java
! src/share/classes/sun/text/resources/vi/FormatData_vi.java
! src/share/classes/sun/text/resources/vi/FormatData_vi_VN.java
+ src/share/classes/sun/text/resources/vi/JavaTimeSupplementary_vi.java
! src/share/classes/sun/text/resources/zh/FormatData_zh.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_CN.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_SG.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java
+ src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh.java
+ src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh_TW.java
! src/share/classes/sun/util/calendar/ZoneInfo.java
! src/share/classes/sun/util/calendar/ZoneInfoFile.java
! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java
! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/LocaleResources.java
! src/share/classes/sun/util/resources/LocaleData.java
! src/share/classes/sun/util/resources/OpenListResourceBundle.java
+ src/share/classes/sun/util/resources/ParallelListResourceBundle.java
! src/share/lib/calendars.properties
+ src/share/lib/hijrah-config-umalqura.properties
! test/java/time/tck/java/time/AbstractDateTimeTest.java
! test/java/time/tck/java/time/TCKClock.java
! test/java/time/tck/java/time/TCKDayOfWeek.java
! test/java/time/tck/java/time/TCKDuration.java
! test/java/time/tck/java/time/TCKInstant.java
! test/java/time/tck/java/time/TCKLocalDate.java
! test/java/time/tck/java/time/TCKLocalDateTime.java
! test/java/time/tck/java/time/TCKLocalTime.java
! test/java/time/tck/java/time/TCKMonth.java
! test/java/time/tck/java/time/TCKMonthDay.java
! test/java/time/tck/java/time/TCKOffsetDateTime.java
! test/java/time/tck/java/time/TCKOffsetTime.java
! test/java/time/tck/java/time/TCKPeriod.java
! test/java/time/tck/java/time/TCKYear.java
! test/java/time/tck/java/time/TCKYearMonth.java
! test/java/time/tck/java/time/TCKZoneId.java
! test/java/time/tck/java/time/TCKZoneOffset.java
! test/java/time/tck/java/time/TCKZonedDateTime.java
- test/java/time/tck/java/time/TestChronology.java
! test/java/time/tck/java/time/TestIsoChronology.java
! test/java/time/tck/java/time/chrono/CopticChronology.java
! test/java/time/tck/java/time/chrono/CopticDate.java
! test/java/time/tck/java/time/chrono/CopticEra.java
+ test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java
+ test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java
+ test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java
! test/java/time/tck/java/time/chrono/TCKChronology.java
+ test/java/time/tck/java/time/chrono/TCKChronologySerialization.java
+ test/java/time/tck/java/time/chrono/TCKHijrahChronology.java
+ test/java/time/tck/java/time/chrono/TCKHijrahEra.java
+ test/java/time/tck/java/time/chrono/TCKIsoChronology.java
+ test/java/time/tck/java/time/chrono/TCKIsoEra.java
+ test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java
+ test/java/time/tck/java/time/chrono/TCKJapaneseEra.java
+ test/java/time/tck/java/time/chrono/TCKMinguoChronology.java
+ test/java/time/tck/java/time/chrono/TCKMinguoEra.java
! test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java
+ test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java
+ test/java/time/tck/java/time/chrono/TCKThaiBuddhistEra.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
! test/java/time/tck/java/time/format/TCKChronoPrinterParser.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java
+ test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java
! test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java
! test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java
! test/java/time/tck/java/time/format/TCKOffsetPrinterParser.java
+ test/java/time/tck/java/time/format/TCKTextStyle.java
! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
! test/java/time/tck/java/time/temporal/TCKIsoFields.java
! test/java/time/tck/java/time/temporal/TCKJulianFields.java
+ test/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java
! test/java/time/tck/java/time/temporal/TCKWeekFields.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
! test/java/time/tck/java/time/zone/TCKFixedZoneRules.java
! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java
! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java
! test/java/time/tck/java/time/zone/TCKZoneRules.java
! test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java
! test/java/time/test/java/time/MockSimplePeriod.java
! test/java/time/test/java/time/TestClock_System.java
! test/java/time/test/java/time/TestDuration.java
! test/java/time/test/java/time/TestLocalDate.java
! test/java/time/test/java/time/TestLocalDateTime.java
! test/java/time/test/java/time/TestLocalTime.java
! test/java/time/test/java/time/TestMonthDay.java
! test/java/time/test/java/time/TestOffsetDateTime.java
! test/java/time/test/java/time/TestOffsetDateTime_instants.java
! test/java/time/test/java/time/TestPeriod.java
! test/java/time/test/java/time/TestZoneId.java
+ test/java/time/test/java/time/chrono/TestChronoLocalDate.java
+ test/java/time/test/java/time/chrono/TestChronologyPerf.java
! test/java/time/test/java/time/chrono/TestExampleCode.java
! test/java/time/test/java/time/chrono/TestIsoChronoImpl.java
+ test/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java
! test/java/time/test/java/time/chrono/TestServiceLoader.java
+ test/java/time/test/java/time/chrono/TestThaiBuddhistChronoImpl.java
+ test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java
! test/java/time/test/java/time/format/AbstractTestPrinterParser.java
! test/java/time/test/java/time/format/MockIOExceptionAppendable.java
! test/java/time/test/java/time/format/TestCharLiteralParser.java
! test/java/time/test/java/time/format/TestCharLiteralPrinter.java
! test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java
! test/java/time/test/java/time/format/TestDateTimeFormatter.java
! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java
! test/java/time/test/java/time/format/TestDateTimeTextProvider.java
! test/java/time/test/java/time/format/TestFractionPrinterParser.java
! test/java/time/test/java/time/format/TestNonIsoFormatter.java
! test/java/time/test/java/time/format/TestNumberParser.java
! test/java/time/test/java/time/format/TestPadPrinterDecorator.java
! test/java/time/test/java/time/format/TestReducedParser.java
! test/java/time/test/java/time/format/TestReducedPrinter.java
! test/java/time/test/java/time/format/TestSettingsParser.java
! test/java/time/test/java/time/format/TestStringLiteralParser.java
! test/java/time/test/java/time/format/TestStringLiteralPrinter.java
! test/java/time/test/java/time/format/TestTextParser.java
! test/java/time/test/java/time/format/TestTextPrinter.java
! test/java/time/test/java/time/format/TestZoneOffsetParser.java
! test/java/time/test/java/time/format/TestZoneOffsetPrinter.java
! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java
! test/java/time/test/java/time/format/ZoneName.java
! test/java/time/test/java/time/temporal/MockFieldValue.java
+ test/java/time/test/java/time/temporal/TestChronoField.java
! test/java/time/test/java/time/temporal/TestChronoUnit.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
! test/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java
! test/java/time/test/java/time/temporal/TestDateTimeValueRange.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java
! test/java/time/test/java/time/zone/TestFixedZoneRules.java
! test/java/time/test/java/util/TestFormatter.java
! test/java/util/Calendar/Bug8007038.java
! test/java/util/Calendar/CldrFormatNamesTest.java
! test/java/util/Calendar/JavatimeTest.java
! test/sun/text/resources/LocaleData
! test/sun/util/calendar/zi/TestZoneInfo310.java

Changeset: 035a61c9f981
Author:    sherman
Date:      2013-04-12 09:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/035a61c9f981

8012123: hijrah-config-umalqura.properties is missing from makefiles/profile-includes.txt
Summary: added the hijrah-config-umalqura.properties into the list
Reviewed-by: alanb

! makefiles/profile-includes.txt

Changeset: e2cd40d7567c
Author:    rfield
Date:      2013-04-12 10:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e2cd40d7567c

8011805: Update sun.tools.java class file reading/writing support to include the new constant pool entries
Reviewed-by: mduigou, alanb

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/sun/tools/java/BinaryConstantPool.java
! src/share/classes/sun/tools/java/RuntimeConstants.java
+ test/sun/tools/java/CFCTest.java

Changeset: 2e3cc7f599ca
Author:    mduigou
Date:      2013-04-10 12:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/2e3cc7f599ca

8011200: (coll) Optimize empty HashMap and ArrayList
Reviewed-by: mduigou, alanb, bchristi, martin
Contributed-by: Sergey Linetskiy , John Rose , Mike Duigou 

! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashMap.java
+ test/java/util/Map/BasicSerialization.java

Changeset: 6c935c5ac7ff
Author:    sherman
Date:      2013-04-12 12:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6c935c5ac7ff

8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime
Summary: added the toInstant()/from(Instant) to FileTime
Reviewed-by: alanb

! src/share/classes/java/nio/file/attribute/FileTime.java
! test/java/nio/file/attribute/FileTime/Basic.java

Changeset: 729ca1ef7c75
Author:    sherman
Date:      2013-04-12 12:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/729ca1ef7c75

8002390: (zipfs) Problems moving files between zip file systems
Summary: fixed the corner cases in zipfs
Reviewed-by: sherman
Contributed-by: mark.sheppard at oracle.com

! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
! test/demo/zipfs/ZipFSTester.java
! test/demo/zipfs/basic.sh

Changeset: d8cae0195fe9
Author:    henryjen
Date:      2013-04-12 12:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d8cae0195fe9

8010279: java.util.Stream.min/max((Comparator)null) is not consistent in throwing (unspecified) NPE
Reviewed-by: alanb, mduigou

! src/share/classes/java/util/Comparators.java
+ test/java/util/Comparators/BasicTest.java
- test/java/util/ComparatorsTest.java

Changeset: 06dfdfa8c3e6
Author:    rfield
Date:      2013-04-12 20:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/06dfdfa8c3e6

8012028: Metafactory-generated lambda classes should be final
8008941: isSynthetic() returns false for lambda instances
Reviewed-by: mduigou

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
+ test/java/lang/invoke/lambda/LambdaClassFinal.java
+ test/java/lang/invoke/lambda/LambdaClassSynthetic.java

Changeset: 0111bab8dc35
Author:    jzavgren
Date:      2013-04-11 12:33 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0111bab8dc35

8008118: (process) Possible null pointer dereference in jdk/src/solaris/native/java/lang/UNIXProcess_md.c
Summary: Modified the path processing code so that it detects and handles out of memory errors.
Reviewed-by: chegar, martin, christos, alanb, msheppar
Contributed-by: john.zavgren at oracle.com

! make/java/java/mapfile-vers
! makefiles/mapfiles/libjava/mapfile-vers
! src/solaris/classes/java/lang/UNIXProcess.java.bsd
! src/solaris/classes/java/lang/UNIXProcess.java.linux
! src/solaris/classes/java/lang/UNIXProcess.java.solaris
! src/solaris/native/java/lang/ProcessEnvironment_md.c
! src/solaris/native/java/lang/UNIXProcess_md.c

Changeset: 5c406a747192
Author:    chegar
Date:      2013-04-14 19:17 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5c406a747192

8011799: CompletableFuture/Basic.java fails intermittently
Reviewed-by: martin, alanb

! test/java/util/concurrent/CompletableFuture/Basic.java

Changeset: 4ed143ddbb8a
Author:    martin
Date:      2013-04-15 14:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4ed143ddbb8a

8008509: 6588413 changed JNIEXPORT visibility for GCC on HSX, jdk's jni_md.h needs similar change
Summary: Define JNIEXPORT to use "default" visibility where possible.
Reviewed-by: coleenp, ddehaven, dcubed, anthony

! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h
! src/share/npt/npt.h
! src/solaris/javavm/export/jni_md.h
! src/solaris/native/sun/awt/awt_LoadLibrary.c

Changeset: baaa706d7677
Author:    darcy
Date:      2013-04-15 18:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/baaa706d7677

8011800: Add java.util.Objects.requireNonNull(T, Supplier)
Reviewed-by: alanb, dholmes, mduigou

! src/share/classes/java/util/Objects.java
! test/java/util/Objects/BasicObjectsTest.java

Changeset: 61cfbe08ce5d
Author:    chegar
Date:      2013-04-16 12:23 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/61cfbe08ce5d

8012343: Objects.requireNonNull(Object,Supplier) breaks genstubs build
Reviewed-by: alanb

! src/share/classes/java/util/Objects.java
! test/java/util/Objects/BasicObjectsTest.java

Changeset: e2a0e37b152c
Author:    chegar
Date:      2013-04-16 12:51 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e2a0e37b152c

8012237: CompletableFuture/Basic.java still fails intermittently
Reviewed-by: martin

! test/java/util/concurrent/CompletableFuture/Basic.java

Changeset: 6135c60e77e5
Author:    chegar
Date:      2013-04-16 13:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6135c60e77e5

8012244: java/net/Socket/asyncClose/Race.java fails intermittently on Windows
Reviewed-by: alanb, dsamersoff

! src/windows/classes/java/net/DualStackPlainSocketImpl.java
! src/windows/native/java/net/SocketInputStream.c
! test/java/net/Socket/asyncClose/Race.java

Changeset: e4e9f6455f3c
Author:    mduigou
Date:      2013-04-16 11:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/e4e9f6455f3c

8004518: Add in-place operations to Map
8010122: Add defaults for ConcurrentMap operations to Map
Reviewed-by: darcy, briangoetz, mduigou, dholmes, ulfzibis
Contributed-by: Doug Lea 
, Henry Jen , Akhil Arora , Peter Levart , Mike Duigou 

! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/concurrent/ConcurrentMap.java
+ test/java/util/Map/Defaults.java

Changeset: c5ead5aa2e13
Author:    bae
Date:      2013-02-07 19:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c5ead5aa2e13

8007014: Improve image handling
Reviewed-by: prr, mschoene, jgodinez

! src/share/classes/sun/awt/image/ByteComponentRaster.java
! src/share/classes/sun/awt/image/BytePackedRaster.java
! src/share/classes/sun/awt/image/IntegerComponentRaster.java
! src/share/classes/sun/awt/image/IntegerInterleavedRaster.java
! src/share/classes/sun/awt/image/ShortComponentRaster.java
! src/share/native/sun/awt/image/awt_parseImage.c
! src/share/native/sun/awt/medialib/awt_ImagingLib.c
! src/share/native/sun/awt/medialib/mlib_ImageCreate.c
! src/share/native/sun/awt/medialib/safe_alloc.h
+ src/share/native/sun/awt/medialib/safe_math.h

Changeset: c95973aac928
Author:    malenkov
Date:      2013-02-08 17:32 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c95973aac928

7200507: Refactor Introspector internals
Reviewed-by: ahgross, art

! src/share/classes/java/beans/ThreadGroupContext.java
+ src/share/classes/java/beans/WeakIdentityMap.java

Changeset: 210fb90ee33a
Author:    michaelm
Date:      2013-02-13 10:40 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/210fb90ee33a

8000724: Improve networking serialization
Summary: delegate InetAddress fields to a holder object
Reviewed-by: alanb, chegar

! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
! src/share/classes/java/net/Inet4Address.java
! src/share/classes/java/net/Inet4AddressImpl.java
! src/share/classes/java/net/Inet6Address.java
! src/share/classes/java/net/Inet6AddressImpl.java
! src/share/classes/java/net/InetAddress.java
! src/share/classes/java/net/InetSocketAddress.java
! src/share/native/java/net/InetAddress.c
! src/share/native/java/net/net_util.c
! src/share/native/java/net/net_util.h
! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c
! src/solaris/native/java/net/NetworkInterface.c
! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/solaris/native/java/net/net_util_md.c
! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java
! src/windows/native/java/net/Inet4AddressImpl.c
! src/windows/native/java/net/Inet6AddressImpl.c
! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/NetworkInterface.h
! src/windows/native/java/net/NetworkInterface_winXP.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c
! src/windows/native/java/net/TwoStacksPlainSocketImpl.c
! src/windows/native/java/net/net_util_md.c

Changeset: 5ffba58b541f
Author:    valeriep
Date:      2013-02-26 11:12 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5ffba58b541f

8000897: VM crash in CompileBroker
Summary: Fixed to use the corresponding digest length when generating output.
Reviewed-by: mullan

! src/share/classes/sun/security/provider/SHA2.java

Changeset: 96890625ebdf
Author:    smarks
Date:      2013-02-27 14:17 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/96890625ebdf

8001040: Rework RMI model
Reviewed-by: alanb, ahgross, coffeys, dmocek

! src/share/classes/sun/rmi/server/MarshalInputStream.java
! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
! test/java/rmi/registry/readTest/readTest.sh
! test/java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java
! test/java/rmi/server/RMIClassLoader/downloadArrayClass/security.policy
! test/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
+ test/java/rmi/server/RMIClassLoader/useCodebaseOnlyDefault/UseCodebaseOnlyDefault.java
! test/java/rmi/testlibrary/RMID.java

Changeset: f12921c0b15b
Author:    dfuchs
Date:      2013-03-14 13:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f12921c0b15b

8001322: Refactor deserialization
Reviewed-by: mchung, skoivu, smarks

! src/share/classes/java/io/ObjectInputStream.java

Changeset: bae4a15265d3
Author:    dmocek
Date:      2013-02-05 16:38 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/bae4a15265d3

8001329: Augment RMI logging
Reviewed-by: smarks, hawtin, alanb

! src/share/classes/java/rmi/server/LogStream.java

Changeset: c876e9321616
Author:    chegar
Date:      2012-12-20 13:40 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c876e9321616

8003335: Better handling of Finalizer thread
Reviewed-by: alanb, ahgross

! src/share/classes/java/lang/ref/Finalizer.java

Changeset: 0c5c54303c92
Author:    serb
Date:      2013-02-15 13:49 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0c5c54303c92

8004261: Improve input validation
Reviewed-by: art, mschoene, amenkov

! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java
! src/share/classes/com/sun/media/sound/FastShortMessage.java
! src/share/classes/com/sun/media/sound/FastSysexMessage.java
! src/share/classes/com/sun/media/sound/MidiOutDevice.java
! src/share/classes/com/sun/media/sound/RealTimeSequencer.java

Changeset: 3d155555f809
Author:    uta
Date:      2013-02-22 17:49 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/3d155555f809

8005942: (process) Improved Runtime.exec
Reviewed-by: alanb, ahgross

! src/share/classes/java/lang/ProcessBuilder.java
! src/windows/classes/java/lang/ProcessImpl.java

Changeset: cf01f2847551
Author:    dsamersoff
Date:      2013-03-05 00:02 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/cf01f2847551

8006435: Improvements in JMX
Summary: Improvements in JMX
Reviewed-by: dfuchs, skoivu, alanb, mchung

! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java

Changeset: 4effe291c08b
Author:    prr
Date:      2013-02-08 09:15 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4effe291c08b

8006795: Improve font warning messages
Reviewed-by: bae, jgodinez

! src/share/classes/sun/font/CMap.java

Changeset: 9b4bee66fa24
Author:    bae
Date:      2013-02-19 11:47 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9b4bee66fa24

8007617: Better validation of images
Reviewed-by: prr, mschoene, jgodinez

! src/share/classes/sun/awt/image/ImageRepresentation.java
! src/share/native/sun/awt/image/awt_ImageRep.c

Changeset: 620a08212c79
Author:    bae
Date:      2013-02-26 00:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/620a08212c79

8007667: Better image reading
Reviewed-by: prr, jgodinez, mschoene

! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
! src/share/native/sun/awt/image/jpeg/imageioJPEG.c

Changeset: 2deab0b85b82
Author:    bae
Date:      2013-02-26 01:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/2deab0b85b82

8007918: Better image writing
Reviewed-by: mschoene, prr, jgodinez

! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java
! src/share/native/sun/awt/image/jpeg/imageioJPEG.c

Changeset: f7b331b8661f
Author:    chegar
Date:      2013-03-03 10:07 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f7b331b8661f

8009063: Improve reliability of ConcurrentHashMap
Reviewed-by: alanb, ahgross

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java

Changeset: 5c2c8fb0b885
Author:    dfuchs
Date:      2013-03-14 18:41 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5c2c8fb0b885

8009305: Improve AWT data transfer
Reviewed-by: art, skoivu, smarks, ant

! src/share/classes/sun/awt/datatransfer/TransferableProxy.java

Changeset: af881cbec91e
Author:    uta
Date:      2013-03-08 13:35 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/af881cbec91e

8009463: Regression test test\java\lang\Runtime\exec\ArgWithSpaceAndFinalBackslash.java failing.
Reviewed-by: alanb, ahgross

! src/windows/classes/java/lang/ProcessImpl.java

Changeset: 633fd0b99a8d
Author:    valeriep
Date:      2013-03-11 20:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/633fd0b99a8d

8009610: Blacklist certificate used with malware.
Summary: updated the black list and the reg test with the new cert.
Reviewed-by: weijun

! src/share/classes/sun/security/util/UntrustedCertificates.java

Changeset: 37296d45a11e
Author:    lancea
Date:      2013-03-18 13:30 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/37296d45a11e

8009814: Better driver management
Reviewed-by: alanb, skoivu

! src/share/classes/java/sql/DriverManager.java

Changeset: fa919c17da9f
Author:    smarks
Date:      2013-03-18 18:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/fa919c17da9f

8009857: Problem with plugin
Reviewed-by: jdn, mchung

! src/share/classes/sun/reflect/misc/MethodUtil.java

Changeset: 4267ae18e13a
Author:    prr
Date:      2013-02-15 13:07 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4267ae18e13a

8008249: Sync ICU into JDK
Reviewed-by: bae, jgodinez

! make/sun/font/FILES_c.gmk
! src/share/native/sun/font/layout/ContextualGlyphInsertion.h
+ src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.cpp
+ src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.h
+ src/share/native/sun/font/layout/ContextualGlyphSubstProc2.cpp
+ src/share/native/sun/font/layout/ContextualGlyphSubstProc2.h
! src/share/native/sun/font/layout/ContextualGlyphSubstitution.h
+ src/share/native/sun/font/layout/GXLayoutEngine2.cpp
+ src/share/native/sun/font/layout/GXLayoutEngine2.h
! src/share/native/sun/font/layout/IndicClassTables.cpp
! src/share/native/sun/font/layout/IndicRearrangement.h
+ src/share/native/sun/font/layout/IndicRearrangementProcessor2.cpp
+ src/share/native/sun/font/layout/IndicRearrangementProcessor2.h
! src/share/native/sun/font/layout/IndicReordering.cpp
! src/share/native/sun/font/layout/IndicReordering.h
! src/share/native/sun/font/layout/LEFontInstance.h
! src/share/native/sun/font/layout/LEGlyphFilter.h
! src/share/native/sun/font/layout/LEInsertionList.h
! src/share/native/sun/font/layout/LEScripts.h
! src/share/native/sun/font/layout/LETypes.h
! src/share/native/sun/font/layout/LayoutEngine.cpp
! src/share/native/sun/font/layout/LayoutEngine.h
+ src/share/native/sun/font/layout/LigatureSubstProc2.cpp
+ src/share/native/sun/font/layout/LigatureSubstProc2.h
! src/share/native/sun/font/layout/LigatureSubstitution.h
! src/share/native/sun/font/layout/LookupProcessor.cpp
! src/share/native/sun/font/layout/MPreFixups.cpp
! src/share/native/sun/font/layout/MorphStateTables.h
! src/share/native/sun/font/layout/MorphTables.h
+ src/share/native/sun/font/layout/MorphTables2.cpp
! src/share/native/sun/font/layout/NonContextualGlyphSubst.h
+ src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.cpp
+ src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.h
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp
! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp
! src/share/native/sun/font/layout/ScriptAndLanguageTags.h
+ src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp
+ src/share/native/sun/font/layout/SegmentArrayProcessor2.h
+ src/share/native/sun/font/layout/SegmentSingleProcessor2.cpp
+ src/share/native/sun/font/layout/SegmentSingleProcessor2.h
+ src/share/native/sun/font/layout/SimpleArrayProcessor2.cpp
+ src/share/native/sun/font/layout/SimpleArrayProcessor2.h
+ src/share/native/sun/font/layout/SingleTableProcessor2.cpp
+ src/share/native/sun/font/layout/SingleTableProcessor2.h
+ src/share/native/sun/font/layout/StateTableProcessor2.cpp
+ src/share/native/sun/font/layout/StateTableProcessor2.h
! src/share/native/sun/font/layout/StateTables.h
+ src/share/native/sun/font/layout/SubtableProcessor2.cpp
+ src/share/native/sun/font/layout/SubtableProcessor2.h
+ src/share/native/sun/font/layout/TrimmedArrayProcessor2.cpp
+ src/share/native/sun/font/layout/TrimmedArrayProcessor2.h

Changeset: 43f2d3d715c5
Author:    prr
Date:      2013-02-26 10:07 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/43f2d3d715c5

8004986: Better handling of glyph table
8004987: Improve font layout
8004994: Improve checking of glyph table
Reviewed-by: srl, jgodinez

! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp
! src/share/native/sun/font/layout/ContextualGlyphSubstProc2.cpp
! src/share/native/sun/font/layout/LETypes.h
! src/share/native/sun/font/layout/LayoutEngine.cpp
! src/share/native/sun/font/layout/LigatureSubstProc.cpp
! src/share/native/sun/font/layout/LigatureSubstProc2.cpp
! src/share/native/sun/font/layout/LookupProcessor.cpp
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h
! src/share/native/sun/font/layout/StateTableProcessor.cpp
! src/share/native/sun/font/layout/StateTableProcessor2.cpp
! src/share/native/sun/font/layout/StateTables.h

Changeset: 32778f4f945f
Author:    prr
Date:      2013-03-07 10:02 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/32778f4f945f

8001031: Better font processing
Reviewed-by: srl, vadim

! src/share/native/sun/font/FontInstanceAdapter.cpp
! src/share/native/sun/font/FontInstanceAdapter.h
! src/share/native/sun/font/fontscalerdefs.h
! src/share/native/sun/font/layout/AlternateSubstSubtables.cpp
! src/share/native/sun/font/layout/AlternateSubstSubtables.h
! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp
! src/share/native/sun/font/layout/ArabicLayoutEngine.h
! src/share/native/sun/font/layout/ArabicShaping.cpp
! src/share/native/sun/font/layout/ArabicShaping.h
! src/share/native/sun/font/layout/AttachmentPosnSubtables.h
! src/share/native/sun/font/layout/CanonData.cpp
! src/share/native/sun/font/layout/CanonShaping.cpp
! src/share/native/sun/font/layout/CanonShaping.h
! src/share/native/sun/font/layout/ClassDefinitionTables.cpp
! src/share/native/sun/font/layout/ClassDefinitionTables.h
! src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.cpp
! src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.h
! src/share/native/sun/font/layout/ContextualGlyphSubstProc.cpp
! src/share/native/sun/font/layout/ContextualGlyphSubstProc.h
! src/share/native/sun/font/layout/ContextualGlyphSubstProc2.cpp
! src/share/native/sun/font/layout/ContextualGlyphSubstProc2.h
! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp
! src/share/native/sun/font/layout/ContextualSubstSubtables.h
! src/share/native/sun/font/layout/CoverageTables.h
! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp
! src/share/native/sun/font/layout/CursiveAttachmentSubtables.h
! src/share/native/sun/font/layout/DeviceTables.h
! src/share/native/sun/font/layout/ExtensionSubtables.cpp
! src/share/native/sun/font/layout/Features.cpp
! src/share/native/sun/font/layout/GDEFMarkFilter.cpp
! src/share/native/sun/font/layout/GDEFMarkFilter.h
! src/share/native/sun/font/layout/GXLayoutEngine.cpp
! src/share/native/sun/font/layout/GXLayoutEngine.h
! src/share/native/sun/font/layout/GXLayoutEngine2.cpp
! src/share/native/sun/font/layout/GXLayoutEngine2.h
! src/share/native/sun/font/layout/GlyphDefinitionTables.cpp
! src/share/native/sun/font/layout/GlyphDefinitionTables.h
! src/share/native/sun/font/layout/GlyphIterator.cpp
! src/share/native/sun/font/layout/GlyphIterator.h
! src/share/native/sun/font/layout/GlyphLookupTables.cpp
! src/share/native/sun/font/layout/GlyphLookupTables.h
! src/share/native/sun/font/layout/GlyphPositioningTables.cpp
! src/share/native/sun/font/layout/GlyphPositioningTables.h
! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp
! src/share/native/sun/font/layout/GlyphPosnLookupProc.h
! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp
! src/share/native/sun/font/layout/GlyphSubstLookupProc.h
! src/share/native/sun/font/layout/GlyphSubstitutionTables.cpp
! src/share/native/sun/font/layout/GlyphSubstitutionTables.h
! src/share/native/sun/font/layout/HanLayoutEngine.cpp
! src/share/native/sun/font/layout/HanLayoutEngine.h
! src/share/native/sun/font/layout/HangulLayoutEngine.cpp
! src/share/native/sun/font/layout/HangulLayoutEngine.h
! src/share/native/sun/font/layout/ICUFeatures.h
! src/share/native/sun/font/layout/IndicLayoutEngine.cpp
! src/share/native/sun/font/layout/IndicLayoutEngine.h
! src/share/native/sun/font/layout/IndicRearrangementProcessor.cpp
! src/share/native/sun/font/layout/IndicRearrangementProcessor.h
! src/share/native/sun/font/layout/IndicRearrangementProcessor2.cpp
! src/share/native/sun/font/layout/IndicRearrangementProcessor2.h
! src/share/native/sun/font/layout/IndicReordering.cpp
! src/share/native/sun/font/layout/KernTable.cpp
! src/share/native/sun/font/layout/KernTable.h
! src/share/native/sun/font/layout/KhmerLayoutEngine.cpp
! src/share/native/sun/font/layout/KhmerLayoutEngine.h
! src/share/native/sun/font/layout/LEScripts.h
+ src/share/native/sun/font/layout/LETableReference.h
! src/share/native/sun/font/layout/LETypes.h
! src/share/native/sun/font/layout/LayoutEngine.cpp
! src/share/native/sun/font/layout/LayoutEngine.h
! src/share/native/sun/font/layout/LigatureSubstProc.cpp
! src/share/native/sun/font/layout/LigatureSubstProc.h
! src/share/native/sun/font/layout/LigatureSubstProc2.cpp
! src/share/native/sun/font/layout/LigatureSubstProc2.h
! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp
! src/share/native/sun/font/layout/LigatureSubstSubtables.h
! src/share/native/sun/font/layout/LookupProcessor.cpp
! src/share/native/sun/font/layout/LookupProcessor.h
! src/share/native/sun/font/layout/LookupTables.cpp
! src/share/native/sun/font/layout/LookupTables.h
! src/share/native/sun/font/layout/Lookups.cpp
! src/share/native/sun/font/layout/Lookups.h
! src/share/native/sun/font/layout/MarkArrays.h
! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp
! src/share/native/sun/font/layout/MarkToBasePosnSubtables.h
! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp
! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.h
! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp
! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.h
! src/share/native/sun/font/layout/MorphTables.cpp
! src/share/native/sun/font/layout/MorphTables.h
! src/share/native/sun/font/layout/MorphTables2.cpp
! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp
! src/share/native/sun/font/layout/MultipleSubstSubtables.h
! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.cpp
! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.h
! src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.cpp
! src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.h
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h
! src/share/native/sun/font/layout/OpenTypeTables.h
! src/share/native/sun/font/layout/OpenTypeUtilities.cpp
! src/share/native/sun/font/layout/OpenTypeUtilities.h
! src/share/native/sun/font/layout/PairPositioningSubtables.cpp
! src/share/native/sun/font/layout/PairPositioningSubtables.h
! src/share/native/sun/font/layout/ScriptAndLanguage.cpp
! src/share/native/sun/font/layout/ScriptAndLanguage.h
! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp
! src/share/native/sun/font/layout/SegmentArrayProcessor.h
! src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp
! src/share/native/sun/font/layout/SegmentArrayProcessor2.h
! src/share/native/sun/font/layout/SegmentSingleProcessor.cpp
! src/share/native/sun/font/layout/SegmentSingleProcessor.h
! src/share/native/sun/font/layout/SegmentSingleProcessor2.cpp
! src/share/native/sun/font/layout/SegmentSingleProcessor2.h
! src/share/native/sun/font/layout/ShapingTypeData.cpp
! src/share/native/sun/font/layout/SimpleArrayProcessor.cpp
! src/share/native/sun/font/layout/SimpleArrayProcessor.h
! src/share/native/sun/font/layout/SimpleArrayProcessor2.cpp
! src/share/native/sun/font/layout/SimpleArrayProcessor2.h
! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp
! src/share/native/sun/font/layout/SinglePositioningSubtables.h
! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp
! src/share/native/sun/font/layout/SingleSubstitutionSubtables.h
! src/share/native/sun/font/layout/SingleTableProcessor.cpp
! src/share/native/sun/font/layout/SingleTableProcessor.h
! src/share/native/sun/font/layout/SingleTableProcessor2.cpp
! src/share/native/sun/font/layout/SingleTableProcessor2.h
! src/share/native/sun/font/layout/StateTableProcessor.cpp
! src/share/native/sun/font/layout/StateTableProcessor.h
! src/share/native/sun/font/layout/StateTableProcessor2.cpp
! src/share/native/sun/font/layout/StateTableProcessor2.h
! src/share/native/sun/font/layout/StateTables.h
! src/share/native/sun/font/layout/SubtableProcessor.cpp
! src/share/native/sun/font/layout/SubtableProcessor.h
! src/share/native/sun/font/layout/SubtableProcessor2.cpp
! src/share/native/sun/font/layout/SubtableProcessor2.h
! src/share/native/sun/font/layout/ThaiLayoutEngine.cpp
! src/share/native/sun/font/layout/TibetanLayoutEngine.cpp
! src/share/native/sun/font/layout/TibetanLayoutEngine.h
! src/share/native/sun/font/layout/TrimmedArrayProcessor.cpp
! src/share/native/sun/font/layout/TrimmedArrayProcessor.h
! src/share/native/sun/font/layout/TrimmedArrayProcessor2.cpp
! src/share/native/sun/font/layout/TrimmedArrayProcessor2.h
! src/share/native/sun/font/layout/ValueRecords.h
! src/share/native/sun/font/sunFont.c

Changeset: 7b03efca912f
Author:    malenkov
Date:      2013-02-05 20:07 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7b03efca912f

8006790: Improve checking for windows
Reviewed-by: art, mschoene

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterDialogPeer.java
! src/share/classes/java/awt/Window.java
! src/share/classes/java/awt/peer/WindowPeer.java
! src/share/classes/sun/awt/EmbeddedFrame.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
! src/windows/classes/sun/awt/windows/WFileDialogPeer.java
! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java
! src/windows/classes/sun/awt/windows/WWindowPeer.java

Changeset: 4ea6d44a20a0
Author:    mullan
Date:      2013-03-27 10:37 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4ea6d44a20a0

8003445: Adjust JAX-WS to focus on API
Reviewed-by: vinnie, ahgross, mgrebac

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/Makefile

Changeset: c921d68edf08
Author:    joehw
Date:      2013-02-18 13:02 -0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/c921d68edf08

6657673: Issues with JAXP
Reviewed-by: alanb, lancea, ahgross, mullan

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/Makefile

Changeset: 6a09e4648cfb
Author:    mkos
Date:      2013-03-07 07:19 -0500
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6a09e4648cfb

8005432: Update access to JAX-WS
Summary: newly restricted the whole package com.sun.xml.internal; fix reviewed also by Alexander Fomin
Reviewed-by: mullan, skoivu

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 12ca12303c33
Author:    raginip
Date:      2013-03-27 21:32 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/12ca12303c33

8007406: Improve accessibility of AccessBridge
Reviewed-by: skoivu, mullan, ptbrunet

! src/share/lib/security/java.security-windows

Changeset: 269b7955a885
Author:    chegar
Date:      2013-03-28 09:50 +0000
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/269b7955a885

8010944: Incorrectly separated package list in java.security-windows
Reviewed-by: mullan

! src/share/lib/security/java.security-windows

Changeset: 7c663f528ff6
Author:    vlivanov
Date:      2013-03-01 04:45 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7c663f528ff6

8008140: Better method handle resolution
Reviewed-by: jrose, twisti, jdn

! src/share/classes/java/lang/invoke/MethodHandles.java

Changeset: 0fb15205acb6
Author:    bae
Date:      2013-02-19 12:06 +0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0fb15205acb6

8007675: Improve color conversion
Reviewed-by: prr, mschoene, jgodinez

! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java

Changeset: b057eaf53935
Author:    chegar
Date:      2013-04-04 17:34 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b057eaf53935

Merge

! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java

Changeset: 5f46a666e06d
Author:    chegar
Date:      2013-04-13 20:16 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5f46a666e06d

Merge

! src/share/classes/sun/awt/EmbeddedFrame.java
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! src/windows/classes/java/lang/ProcessImpl.java
! test/Makefile

Changeset: 84df34924f67
Author:    chegar
Date:      2013-04-13 21:51 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/84df34924f67

Merge

- src/share/classes/java/time/chrono/HijrahDeviationReader.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
- src/share/classes/java/time/temporal/Adjusters.java
- src/share/classes/java/time/temporal/Queries.java
- test/java/time/tck/java/time/TestChronology.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java
- test/java/util/ComparatorsTest.java

Changeset: 9246b0fee2f2
Author:    chegar
Date:      2013-04-16 13:30 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/9246b0fee2f2

Merge


Changeset: 10fd3b4a77ae
Author:    chegar
Date:      2013-04-16 21:04 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/10fd3b4a77ae

Merge


Changeset: a3cc4b8e217a
Author:    weijun
Date:      2013-04-17 10:15 +0800
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a3cc4b8e217a

8011124: Make KerberosTime immutable
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/KrbApReq.java
! src/share/classes/sun/security/krb5/KrbAppMessage.java
! src/share/classes/sun/security/krb5/KrbCred.java
! src/share/classes/sun/security/krb5/KrbTgsReq.java
! src/share/classes/sun/security/krb5/internal/KerberosTime.java
! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java
! src/share/classes/sun/security/krb5/internal/LastReqEntry.java
! src/share/classes/sun/security/krb5/internal/PAEncTSEnc.java
! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java
! test/sun/security/krb5/MicroTime.java

Changeset: da6addef956e
Author:    mchung
Date:      2013-04-16 21:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/da6addef956e

8010117: Annotate jdk caller sensitive methods with @sun.reflect.CallerSensitive
Reviewed-by: jrose, alanb, twisti

! make/java/java/FILES_c.gmk
! make/java/java/mapfile-vers
! make/java/java/reorder-i586
! make/java/java/reorder-sparc
! make/java/java/reorder-sparcv9
! makefiles/mapfiles/libjava/mapfile-vers
! makefiles/mapfiles/libjava/reorder-sparc
! makefiles/mapfiles/libjava/reorder-sparcv9
! makefiles/mapfiles/libjava/reorder-x86
! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/ClassLoader.java
! src/share/classes/java/lang/Package.java
! src/share/classes/java/lang/Runtime.java
! src/share/classes/java/lang/SecurityManager.java
! src/share/classes/java/lang/System.java
! src/share/classes/java/lang/Thread.java
! src/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/java/security/AccessController.java
! src/share/classes/java/sql/DriverManager.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
! src/share/classes/java/util/logging/Logger.java
! src/share/classes/javax/script/ScriptEngineManager.java
! src/share/classes/sun/misc/Unsafe.java
+ src/share/classes/sun/reflect/CallerSensitive.java
! src/share/classes/sun/reflect/Reflection.java
! src/share/javavm/export/jvm.h
! src/share/native/java/lang/ClassLoader.c
- src/share/native/java/lang/ResourceBundle.c
! src/share/native/java/lang/SecurityManager.c
! src/share/native/sun/reflect/Reflection.c
! test/Makefile
+ test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java
+ test/sun/reflect/CallerSensitive/MethodFinder.java
+ test/sun/reflect/CallerSensitive/MissingCallerSensitive.java
+ test/sun/reflect/Reflection/GetCallerClass.java
+ test/sun/reflect/Reflection/GetCallerClassTest.java
+ test/sun/reflect/Reflection/GetCallerClassTest.sh

Changeset: 414384c3b3eb
Author:    yhuang
Date:      2013-04-16 22:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/414384c3b3eb

8011977: ISO 4217 Amendment Number 155
Reviewed-by: naoto

! src/share/classes/java/util/CurrencyData.properties
! test/java/util/Currency/tablea1.txt

Changeset: 779ba708fee3
Author:    yhuang
Date:      2013-04-17 01:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/779ba708fee3

Merge

- src/share/native/java/lang/ResourceBundle.c

Changeset: 473ed4b94306
Author:    vinnie
Date:      2013-04-11 17:57 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/473ed4b94306

7171982: Cipher getParameters() throws RuntimeException: Cannot find SunJCE provider
Reviewed-by: vinnie, wetmore
Contributed-by: Tony Scarpino 

! src/share/classes/com/sun/crypto/provider/CipherCore.java
! src/share/classes/com/sun/crypto/provider/CipherWithWrappingSpi.java
! src/share/classes/com/sun/crypto/provider/ConstructKeys.java
! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java
! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java
! src/share/classes/com/sun/crypto/provider/KeyProtector.java
! src/share/classes/com/sun/crypto/provider/PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/PBES1Core.java
! src/share/classes/com/sun/crypto/provider/PBES2Core.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/RSACipher.java
! src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java
! src/share/classes/com/sun/crypto/provider/SunJCE.java
+ test/com/sun/crypto/provider/Cipher/UTIL/SunJCEGetInstance.java

Changeset: a6ca7cd399b2
Author:    vinnie
Date:      2013-04-11 18:00 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a6ca7cd399b2

8001596: Incorrect condition check in PBKDF2KeyImpl.JAVA
Reviewed-by: wetmore
Contributed-by: Tony Scarpino 

! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
+ test/com/sun/crypto/provider/Cipher/PBE/NegativeLength.java

Changeset: 747a09471fd9
Author:    erikj
Date:      2013-04-11 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/747a09471fd9

8011812: JDK-8011278 breaks the old build
Reviewed-by: tbell, wetmore

! make/sun/splashscreen/Makefile

Changeset: 793e0072bfd6
Author:    wetmore
Date:      2013-04-11 17:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/793e0072bfd6

8012056: SunJCEInstance needs to run in it's own vm
Reviewed-by: wetmore
Contributed-by: anthony.scarpino at oracle.com

! test/com/sun/crypto/provider/Cipher/UTIL/SunJCEGetInstance.java

Changeset: d8d037a7569e
Author:    xuelei
Date:      2013-04-11 18:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d8d037a7569e

8011680: Re-integrate AEAD implementation of JSSE
Summary: It is a re-merge of JDK-7030966.
Reviewed-by: wetmore

! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java
! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java
+ src/share/classes/sun/security/ssl/Authenticator.java
! src/share/classes/sun/security/ssl/CipherBox.java
! src/share/classes/sun/security/ssl/CipherSuite.java
! src/share/classes/sun/security/ssl/EngineInputRecord.java
! src/share/classes/sun/security/ssl/EngineOutputRecord.java
! src/share/classes/sun/security/ssl/EngineWriter.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/InputRecord.java
! src/share/classes/sun/security/ssl/JsseJce.java
! src/share/classes/sun/security/ssl/MAC.java
! src/share/classes/sun/security/ssl/OutputRecord.java
! src/share/classes/sun/security/ssl/Record.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! test/sun/security/ec/TestEC.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/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
+ test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java
! test/sun/security/ssl/sanity/interop/CipherTest.java
! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java

Changeset: ea7976ed9bc6
Author:    wetmore
Date:      2013-04-11 19:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/ea7976ed9bc6

Merge


Changeset: 0f93bd5cc8d7
Author:    wetmore
Date:      2013-04-11 21:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/0f93bd5cc8d7

6425477: Better support for generation of high entropy random numbers
Reviewed-by: xuelei, weijun, mullan

! src/share/classes/java/security/SecureRandom.java
! src/share/classes/sun/security/pkcs11/P11SecureRandom.java
! src/share/classes/sun/security/provider/SecureRandom.java
! src/share/classes/sun/security/provider/SeedGenerator.java
! src/share/classes/sun/security/provider/SunEntries.java
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! src/solaris/classes/sun/security/provider/NativePRNG.java
! src/solaris/classes/sun/security/provider/NativeSeedGenerator.java
! src/windows/classes/sun/security/mscapi/PRNG.java
! src/windows/classes/sun/security/provider/NativePRNG.java
! src/windows/classes/sun/security/provider/NativeSeedGenerator.java
+ test/sun/security/provider/SecureRandom/StrongSecureRandom.java
+ test/sun/security/provider/SecureRandom/StrongSeedReader.java

Changeset: 5435f112e5ea
Author:    vinnie
Date:      2013-04-12 10:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/5435f112e5ea

Merge

- src/share/classes/java/time/chrono/HijrahDeviationReader.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
- src/share/classes/java/time/temporal/Adjusters.java
- src/share/classes/java/time/temporal/Queries.java
- test/java/time/tck/java/time/TestChronology.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java

Changeset: 6f80a6584fb9
Author:    vinnie
Date:      2013-04-16 01:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/6f80a6584fb9

Merge

- test/java/util/ComparatorsTest.java

Changeset: 29cbb4617c92
Author:    vinnie
Date:      2013-04-16 05:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/29cbb4617c92

Merge


Changeset: 13e18d3ac414
Author:    vinnie
Date:      2013-04-16 05:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/13e18d3ac414

Merge


Changeset: f90b7503019f
Author:    vinnie
Date:      2013-04-17 02:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f90b7503019f

Merge

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
- src/share/native/java/lang/ResourceBundle.c

Changeset: 7ded74ffea36
Author:    alanb
Date:      2013-04-17 16:11 +0100
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7ded74ffea36

8012019: (fc) Thread.interrupt triggers hang in FileChannelImpl.pread (win)
Reviewed-by: chegar

! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/NativeDispatcher.java
! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java
! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java
! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java
+ test/java/nio/channels/FileChannel/InterruptDeadlock.java

Changeset: d9f9040554d6
Author:    mduigou
Date:      2013-04-17 11:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/d9f9040554d6

8010953: Add primitive summary statistics utils
Reviewed-by: mduigou, dholmes, chegar, darcy
Contributed-by: Brian Goetz 

+ src/share/classes/java/util/DoubleSummaryStatistics.java
+ src/share/classes/java/util/IntSummaryStatistics.java
+ src/share/classes/java/util/LongSummaryStatistics.java

Changeset: 73e3b474125e
Author:    mchung
Date:      2013-04-17 12:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/73e3b474125e

8004260: dynamic proxy class should have the same Java language access as the proxy interfaces
Reviewed-by: alanb, jrose, jdn

! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/java/lang/reflect/ReflectPermission.java
! src/share/classes/sun/misc/ProxyGenerator.java
! src/share/classes/sun/reflect/annotation/AnnotationParser.java
! src/share/classes/sun/rmi/server/Util.java
! src/share/classes/sun/tracing/ProviderSkeleton.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/SimpleProxy.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/p/Bar.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/p/Foo.java
! test/java/rmi/server/RMIClassLoader/loadProxyClasses/security.policy

Changeset: 7f9f69729934
Author:    coleenp
Date:      2013-04-17 12:50 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7f9f69729934

8009531: Crash when redefining class with annotated method
Summary: Add code to annotated methods and command line flags to the tests to verify bug above
Reviewed-by: acorn, sspitsyn, dcubed, dholmes, alanb

! test/java/lang/instrument/RedefineMethodWithAnnotations.sh
! test/java/lang/instrument/RedefineMethodWithAnnotationsTarget.java
! test/java/lang/instrument/RedefineMethodWithAnnotationsTarget_2.java

Changeset: 36f9e357b84b
Author:    coleenp
Date:      2013-04-17 15:06 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/36f9e357b84b

Merge


Changeset: a954e407680c
Author:    lana
Date:      2013-04-17 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a954e407680c

Merge


Changeset: 17dcb75682b7
Author:    lana
Date:      2013-04-17 12:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/17dcb75682b7

Merge


Changeset: 131686bea632
Author:    lana
Date:      2013-04-17 12:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/131686bea632

Merge


Changeset: 674880648db4
Author:    briangoetz
Date:      2013-04-16 13:51 -0400
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/674880648db4

8010096: Initial java.util.Spliterator putback
Reviewed-by: mduigou, alanb, chegar, darcy
Contributed-by: Paul Sandoz , Brian Goetz , Doug Lea 


! src/share/classes/com/sun/tools/jdi/EventSetImpl.java
! src/share/classes/java/lang/Iterable.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/Iterator.java
! src/share/classes/java/util/List.java
+ src/share/classes/java/util/PrimitiveIterator.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedSet.java
+ src/share/classes/java/util/Spliterator.java
+ src/share/classes/java/util/Spliterators.java
+ src/share/classes/java/util/Tripwire.java
+ test/java/util/Spliterator/SpliteratorLateBindingFailFastTest.java
+ test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java

Changeset: 4b8e606f8afb
Author:    lana
Date:      2013-04-17 21:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/4b8e606f8afb

Merge

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
- src/share/classes/java/time/chrono/HijrahDeviationReader.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
- src/share/classes/java/time/temporal/Adjusters.java
- src/share/classes/java/time/temporal/Queries.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
- src/share/native/java/lang/ResourceBundle.c
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
- test/java/time/tck/java/time/TestChronology.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java
- test/java/util/ComparatorsTest.java

Changeset: 10ad4a4330bc
Author:    lana
Date:      2013-04-23 09:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/10ad4a4330bc

Merge




From bourges.laurent at gmail.com  Wed Apr 24 08:59:58 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Wed, 24 Apr 2013 10:59:58 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: <5177345D.4060408@oracle.com>
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
	
	
	<5175A611.9080004@oracle.com>
	
	<5177345D.4060408@oracle.com>
Message-ID: 

Jim,

First, here are both updated webrev and benchmark results:
- results: http://jmmc.fr/~bourgesl/share/java2d-pisces/patch_opt_night.log
- webrev: http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-2/

Note: the webrev is partially "cleaner" - work still in progress !

Changes made:
- optimized cleanup of alpha / edges arrays
- TileState HARD reference stored in SunGraphics2D to avoid repeated
ThreadLocal or ConcurrentQueue accesses
- TileState propagated in RenderingEngine to PiscesRenderingEngine:
warning: interface compatibility issues
- minor tuning.

Now the ArrayCache (IntArrayCache, Dirty... and FloatArrayCache) are
totally useless during MapBench tests as the RendererContext stores large
arrays (16K int or float arrays) + rowAARLE (2Mb).
However, I keep the array caching for very high workload ... to be
discussed later.

Comparison (open office format):
http://jmmc.fr/~bourgesl/share/java2d-pisces/compareRef_Patch.ods

Patch2 vs ductus:
   1 *102,11%*  2 *144,49%*  4 *263,13%*
In average, patch2 is equal or better than ductus: 44% for 2 threads and
2.6 times for 4 threads !

In the following table, you can see gain variations depending on the test
(work load): my patch performs better than ductus for complex test case
only.

   test threads Tavg Tmed *Med+Stddev*  boulder_17 1 82,54% 77,68% *76,99%*
boulder_17 2 119,57% 120,24% *128,56%*  boulder_17 4 149,95% 150,39% *
161,98%*  shp_alllayers_47 1 107,26% 107,18% *107,02%*  shp_alllayers_47 2
144,24% 144,18% *147,00%*  shp_alllayers_47 4 288,05% 289,10% *286,04%*
Secondly, here are my comments:

2013/4/24 Jim Graham 

>
> Originally the version that was used in embedded used RLE because it
> stored the results in the shape itself.  On desktop I never found that to
> be a necessary optimization especially because it actually wastes memory
> for no gain during animations, but that was why they used RLE as a storage
> format.  Would it speed up the code to use a different storage format?
>

Maybe it could be a very good idea: compressing alpha array to RLE and then
decompressing it to fill byte[] tile array seems a bad idea. However,
keeping RLE encoding may help having smaller arrays to store a complete
tile line as I want: width = 4096 (or more) x height = 32.

As memory is cheap nowadays, I could try having a large 1D array to store
alpha values for complete tile line: 512K only !


> Also, in the version we use in JavaFX we removed the tiling altogether and
> return one alpha array for the entire rasterization.  We might consider
> doing that for this code as well if it allows us to get rid of Ductus - it
> was a Ductus design constraint that forced the tiling (it was again based
> on the expected size of the hardware AA engine)...
>

I think tiling is still interesting as such small arrays stay in the cpu
cache ! however, I could try tuning the tile width to be larger (256x32)
instead of (32x32 tiles) ...


Finally,
Who could help me working on pisces ? Could we form a tiger team ?
or at least could denis and you have some time to help me ?

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From anton.litvinov at oracle.com  Wed Apr 24 16:53:39 2013
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Wed, 24 Apr 2013 20:53:39 +0400
Subject: [OpenJDK 2D-Dev] [8] Review request for 8005607: Recursion in
 J2DXErrHandler() Causes a Stack Overflow on Linux
In-Reply-To: <517534F0.3070905@oracle.com>
References: <50DEF3AC.2070600@oracle.com> <50ED9609.1070002@oracle.com>
	<50EE1CEB.5080500@oracle.com> <50EFED12.6070700@oracle.com>
	<50EFFB4F.4090405@oracle.com> <510946F7.3090709@oracle.com>
	<510A6A54.1080705@oracle.com> <510A90DF.2060501@oracle.com>
	<511BC5E4.9090302@oracle.com> <51220DA4.7040608@oracle.com>
	<512218E7.9090808@oracle.com> <51221D2D.9070907@oracle.com>
	<512251F0.7020204@oracle.com> <5124D315.8080809@oracle.com>
	<51519754.7010906@oracle.com> <5152011C.9070202@oracle.com>
	<51536DE1.1090508@oracle.com> <515373E9.1070609@oracle.com>
	<517534F0.3070905@oracle.com>
Message-ID: <51780E13.1060902@oracle.com>

Hello Phil,

I provide answers to the questions from your last e-mail. Yes, the fix 
for the bug 6678385 did not take into account error handlers which are 
set in 2D native code area. Thank you for accepting the idea of the fix, 
despite theoretically possible problems, which you defined for the 
cases, when Java is embedded into another applications. No, after 
discussion with AWT team member Anthony Petrov, I would not like to 
remove "saved_error_handler" variable from the class 
"XErrorHandlerUtil", because, as Anthony stated in his last e-mail in 
the mail thread dedicated to this fix, this variable may be used for 
debugging purpose at any time and its removal is not directly related to 
the main purpose of this fix.

Could you please review a new version of the fix containing corrections 
which should satisfy your remarks.

Webrev: http://cr.openjdk.java.net/~alitvinov/8005607/webrev.05

The following changes were added to the fix:

1. Declarations of the local variables introduced by the fix in all C 
source files were moved to the beginning of the functions in order not 
to lead to warnings or errors of some C source code compilers. The fix 
in these files was modified: awt_GraphicsEnv.c, awt_util.h, 
GLXSurfaceData.c, X11SurfaceData.c.

2. The code AWT_LOCK/AWT_UNLOCK was eliminated from both files 
"GLXSurfaceData.c" and "X11SurfaceData.c", where it was added by the 
earlier version of the fix. Because:

     - "sun.java2d.opengl.GLXSurfaceData.initPbuffer" method, whose 
native implementation contains the fix, is always called under AWT lock, 
acquired in the method "sun.java2d.opengl.OGLSurfaceData.initSurface".
     - "X11SurfaceData.c::X11SD_CreateSharedPixmap" calling 
"X11SurfaceData.c::X11SD_CreateSharedImage" function, containing the 
fix, is always guarded by AWT lock, acquired in 
"X11SurfaceData.c::XShared_initSurface" function.
     - Despite of the fact that I was not able to find evidences of 
acquirement of AWT lock in all other algorithm's paths, which lead to a 
call of the function "X11SurfaceData.c::X11SD_CreateSharedImage", I 
tested the fix with manual test and did not observe any case, when 
"sun.awt.X11.XShmAttachHandler" was exploited without AWT lock by means 
of the method "SunToolkit.isAWTLockHeldByCurrentThread". I also suppose 
that small possibility of race condition is less important than a 
deadlock caused by AWT_LOCK/AWT_UNLOCK code.

Thank you,
Anton

On 4/22/2013 5:02 PM, Anthony Petrov wrote:
>>> I also do not know the point of saved_error_handler variable, it 
>>> became unusable with the fix for the bug "6678385", but this seems 
>>> to be a stable code which I just had to move from XToolkit class to 
>>> XErrorHandlerUtil without any modification.
>>
>> So maybe remove it ? Ask the AWT folks what they think.
>
> The variable occupies 8 bytes only. It also allows one to uncomment 
> the line:
>
>>  120             // return 
>> XlibWrapper.CallErrorHandler(saved_error_handler, display, error.pData);
>
> for debugging purposes w/o having to wire up all the 
> saved_error_handler machinery anew. This is needed rarely but may be 
> useful in some cases.
>
> I'd prefer to leave it as is.
>
> -- 
> best regards,
> Anthony
>
> On 03/28/13 02:34, Phil Race wrote:
>> Hello,
>>
>> On 3/27/2013 3:08 PM, Anton Litvinov wrote:
>>> Hello Phil,
>>>
>>> Thank you very much for the review. No, the original problem consists
>>> in the fact that Xlib function "XSetErrorHandler" is not thread-safe,
>>> so calling it from different threads by setting one error handler and
>>> restoring the previous error handler leads to
>>
>> I get that. The MT case is just the mechanism for what I described,
>> because the install/restore
>> was wrapping the code that needed the special handler.
>>
>>
>>> such not easily reproducible bugs like this and the already fixed
>>> 6678385, for example when the second thread restores error handler set
>>> by the first thread after the first thread left the code block
>>> potentially generating XError and already unset its error handler. The
>>> only solution to this problem is introduction of one critical section
>>> for all pairs of calls to "XSetErrorHandler" function through
>>> WITH_XERROR_HANDLER, RESTORE_XERROR_HANDLER macros in the code of JDK.
>>> Even this solution is not complete, because JDK's code cannot
>>> influence invoked by it code from the third-party libraries, which
>>> also sets or potentially sets own error handlers. The purpose of the
>>> fix for "6678385" bug was to guarantee that AWT code sets its global
>>> error handler once and for the whole life time of Java application and
>>> allows Java code to set "synthetic" or not real error handlers without
>>> invocation of "XSetErrorHandler" function. While the idea of this fix
>>> is to guarantee that there is no place in JDK other than
>>> "src/solaris/native/sun/xawt/XlibWrapper.c", where "XSetErrorHandler"
>>> function is called. So this fix substitutes real calls to that native
>>> function for setting of "synthetic" error handlers through
>>> "sun.awt.X11.XErrorHandlerUtil" class.
>>
>> Except that 6678385 apparently didn't include the two 2D handlers ? Just
>> the XAWT ones.
>>
>>>
>>> Yes, this pattern follows a policy relying on the assumption that no
>>> other code has a "more important" need to have its X error handler
>>> installed, but with one correction which is "no other code in JDK". So
>>> this constraint is not applicable to a code of any third-party
>>> library, since it is impossible without collaboration between JDK and
>>> third parties on definition of common critical section. Unfortunately,
>>> I did not know about the opportunity of embedding Java application
>>> into another application.
>>
>> Isn't that exactly what the SWT /AWT bridge is, which is what started
>> off 6678385 ?
>> Fortunately that doesn't seem to rely on this behaviour and in fact
>> needed 667838.
>> But I also wonder about embedding AWT into FX too ..
>>
>> So I don't know of actual problems for specific apps, but it seems
>> theoretically possible.
>> If this was already policy for XAWT we likely have this issue anyway so
>> I suppose we
>> just go with this approach until its proven to be a problem.
>>
>>>
>>> I also do not know the point of saved_error_handler variable, it
>>> became unusable with the fix for the bug "6678385", but this seems to
>>> be a stable code which I just had to move from XToolkit class to
>>> XErrorHandlerUtil without any modification.
>>
>> So maybe remove it ? Ask the AWT folks what they think.
>>
>>>
>>> AWT_LOCK/AWT_UNLOCK code was added to guarantee that no other thread
>>> from JDK code both Java and native can set and unset synthetic error
>>> handlers simultaneously. This is the critical section, which I
>>> described in my first passage of this e-mail.
>>
>> That didn't completely answer the point. It wasn't needed before, so did
>> you see a real problem ?
>> It looked to me like we only get here if we have the AWT_LOCK anyway,
>> but I didn't exhaustively trace.
>>
>> -phil.
>>
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 3/27/2013 12:12 AM, Phil Race wrote:
>>>> If I correctly understand the original problem it was that
>>>> the restoration of an X Error Handler was expected to be
>>>> to the original one installed by the XToolkit but there is
>>>> no guarantee of that, so the essence of this fix is
>>>> that we install our error handlers as we need them but
>>>> then RESTORE_XERROR_HANDLER() is a bit of a misnomer since
>>>> it really leaves the handler installed (as far as X11 is concerned)
>>>> and in the Java code simply discardscurrent_error_handler.
>>>> Then if an error occurs the Java code will fall through to
>>>> SAVED_XERROR_HANDLER() which just ignores it.
>>>>
>>>> I suppose this policy relies on the assumption that no other
>>>> code has a "more important" need to have its X error handler
>>>> installed, so we have no obligation to restore it after we are done.
>>>> I wonder if this is the right thing to do if we are embedded in
>>>> another application.
>>>>
>>>> And I am not sure what the point is of saved_error_handler
>>>> in XErrorHandlerUtil.java since you never use it.
>>>>
>>>>
>>>> 561 JNIEnv* env = (JNIEnv*)JNU_GetEnv(jvm, JNI_VERSION_1_2);
>>>> 562 AWT_LOCK();
>>>> 563 jboolean xShmAttachResult = TryXShmAttach(env, awt_display,
>>>> shminfo);
>>>> 564 AWT_UNLOCK();
>>>>
>>>> embedding these declarations in the middle of the function
>>>> may trigger a C compiler warning or error depending on the compiler.
>>>> Best to move the declarations. Same in the other file.
>>>>
>>>> I'm curious, why did you add the AWT_LOCK/AWT_UNLOCK which was not
>>>> there before?
>>>> It may have been considered 'harmless' even if we already have the
>>>> lock on this thread and its
>>>> a Reentrant lock but it does increase the risk of deadlock, plus its
>>>> got JNI up-call overhead ..
>>>> but we seem to have a ton of that anyway.
>>>>
>>>> -phil.
>>>>
>>>> On 3/26/2013 5:40 AM, Anton Litvinov wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following fix for a bug. The fix passed 3 cycles
>>>>> of review by AWT development team. Artem Ananiev and Anthony Petrov
>>>>> approved it. But because the fix modifies also Java 2D Graphics
>>>>> code, review by 2D Graphics development team is necessary. New
>>>>> "webrev.04" was generated to resolve problem in not smooth patching
>>>>> of the latest version of the file
>>>>> "src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c".
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005607
>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8005607/webrev.04
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>>
>>>>> On 2/20/2013 5:43 PM, Artem Ananiev wrote:
>>>>>>
>>>>>> Looks fine.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>> On 2/18/2013 8:08 PM, Anton Litvinov wrote:
>>>>>>> Hello Artem,
>>>>>>>
>>>>>>> Could you please review a new version of the fix. The method
>>>>>>> "XErrorHandlerUtil.getDisplay()" was removed and
>>>>>>> "XErrorHandlerUtil.XSync()" method refers to the field "display"
>>>>>>> directly now.
>>>>>>>
>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8005607/webrev.03
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Anton
>>>>>>>
>>>>>>> On 2/18/2013 4:23 PM, Artem Ananiev wrote:
>>>>>>>>
>>>>>>>> On 2/18/2013 4:04 PM, Anton Litvinov wrote:
>>>>>>>>> Hello Artem,
>>>>>>>>>
>>>>>>>>> Thank you very much for the review of this fix. My responses to
>>>>>>>>> your
>>>>>>>>> questions are provided below in the same order, which you 
>>>>>>>>> defined.
>>>>>>>>>
>>>>>>>>> 1. I think that "XErrorHandlerUtil.saved_error" field can 
>>>>>>>>> surely be
>>>>>>>>> marked as private, but in this case the corresponding
>>>>>>>>> "XErrorHandlerUtil.getSavedError" method will be necessary, 
>>>>>>>>> because
>>>>>>>>> this field is actively accessed from other classes which set a
>>>>>>>>> certain instance of XErrorHandler. For example
>>>>>>>>> "MotifDnDDropTargetProtocol.java", "XDragSourceProtocol.java" 
>>>>>>>>> and a
>>>>>>>>> few other classes edited in this fix.
>>>>>>>>
>>>>>>>> OK, I missed that usages when looking at the webrev. Let it stay
>>>>>>>> unchanged now.
>>>>>>>>
>>>>>>>>> 2. Yes, I completely agree that 
>>>>>>>>> "XErrorHandlerUtil.getDisplay()" is
>>>>>>>>> reduntant. This method will be eliminated.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Artem
>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Anton
>>>>>>>>>
>>>>>>>>> On 2/18/2013 3:16 PM, Artem Ananiev wrote:
>>>>>>>>>> Hi, Anton,
>>>>>>>>>>
>>>>>>>>>> a few minor comments:
>>>>>>>>>>
>>>>>>>>>> 1. XErrorHandlerUtil: can saved_error be private instead of
>>>>>>>>>> package
>>>>>>>>>> protected?
>>>>>>>>>>
>>>>>>>>>> 2. XErrorHandlerUtil.getDisplay() seems to be redundant.
>>>>>>>>>>
>>>>>>>>>> In general, the fix looks perfectly fine to me. Please, wait for
>>>>>>>>>> comments from Java2D team, though.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Artem
>>>>>>>>>>
>>>>>>>>>> On 2/13/2013 8:57 PM, Anton Litvinov wrote:
>>>>>>>>>>> Hello Anthony,
>>>>>>>>>>>
>>>>>>>>>>> Could you please review the third version of the fix containing
>>>>>>>>>>> modifications discussed with you in the previous letter.
>>>>>>>>>>>
>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8005607/webrev.02
>>>>>>>>>>>
>>>>>>>>>>> This version of the fix differs from the previous in the
>>>>>>>>>>> following
>>>>>>>>>>> places:
>>>>>>>>>>>
>>>>>>>>>>> 1. A comment about the place of invocation of the method
>>>>>>>>>>> "XErrorHandlerUtil.init" was added to a documentation block of
>>>>>>>>>>> the
>>>>>>>>>>> method.
>>>>>>>>>>> 2. A code related to XShmAttach function common to the files
>>>>>>>>>>> "src/solaris/native/sun/awt/awt_GraphicsEnv.c" and
>>>>>>>>>>> "src/solaris/native/sun/java2d/x11/X11SurfaceData.c" was
>>>>>>>>>>> extracted
>>>>>>>>>>> into a separate function "TryXShmAttach" declared in
>>>>>>>>>>> "src/solaris/native/sun/awt/awt_GraphicsEnv.h" file.
>>>>>>>>>>> 3. All JNI code related to X error handling was implemented as
>>>>>>>>>>> corresponding macros defined in
>>>>>>>>>>> "src/solaris/native/sun/awt/awt_util.h" file.
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Anton
>>>>>>>>>>>
>>>>>>>>>>> On 1/31/2013 7:42 PM, Anton Litvinov wrote:
>>>>>>>>>>>> Hello Anthony,
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you for the review and these remarks. Surely, the
>>>>>>>>>>>> comment will
>>>>>>>>>>>> be added. I think that all JNI code related to XShmAttach 
>>>>>>>>>>>> can be
>>>>>>>>>>>> definitely transferred into a separate dedicated function,
>>>>>>>>>>>> which will
>>>>>>>>>>>> be declared in "src/solaris/native/sun/awt/awt_GraphicsEnv.h"
>>>>>>>>>>>> file. I
>>>>>>>>>>>> will try to wrap all JNU calls connected with XErrorHandler
>>>>>>>>>>>> into the
>>>>>>>>>>>> particular "WITH_XERROR_HANDLER", "RESTORE_XERROR_HANDLER"
>>>>>>>>>>>> functions
>>>>>>>>>>>> or macros.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you,
>>>>>>>>>>>> Anton
>>>>>>>>>>>>
>>>>>>>>>>>> On 1/31/2013 4:57 PM, Anthony Petrov wrote:
>>>>>>>>>>>>> Hi Anton,
>>>>>>>>>>>>>
>>>>>>>>>>>>> A couple comments:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. src/solaris/classes/sun/awt/X11/XErrorHandlerUtil.java
>>>>>>>>>>>>>> 80 private static void init(long display) {
>>>>>>>>>>>>>
>>>>>>>>>>>>> This method is private and isn't called from anywhere in
>>>>>>>>>>>>> this class
>>>>>>>>>>>>> itself. This looks confusing. Please add a comment stating
>>>>>>>>>>>>> that this
>>>>>>>>>>>>> method is invoked from native code, and from where exactly.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2. Interesting that we use this machinery to call the
>>>>>>>>>>>>> XShmAttach()
>>>>>>>>>>>>> from native code twice, and the code looks quite similar in
>>>>>>>>>>>>> each
>>>>>>>>>>>>> case. Would it be possible to extract the common code in a
>>>>>>>>>>>>> separate
>>>>>>>>>>>>> function (a-la BOOL TryXShmAttach(...)) to avoid code
>>>>>>>>>>>>> replication?
>>>>>>>>>>>>> There are other usages as well, so we could also introduce a
>>>>>>>>>>>>> macro
>>>>>>>>>>>>> (such as the old EXEC_WITH_XERROR_HANDLER but now with other
>>>>>>>>>>>>> arguments) that would minimize all the JNU_ calls required
>>>>>>>>>>>>> to use
>>>>>>>>>>>>> this machinery.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Otherwise the fix looks great.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- 
>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 1/30/2013 20:14, Anton Litvinov wrote:
>>>>>>>>>>>>>> Hello Anthony,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could you, please, review a second version of the fix,
>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>> based on an idea of reusing the existing AWT native global
>>>>>>>>>>>>>> error
>>>>>>>>>>>>>> handler from Java 2D native code.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Webrev:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8005607/webrev.01
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The fix consists of the following parts:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Migration of all X error handling code from XToolkit to
>>>>>>>>>>>>>> a new
>>>>>>>>>>>>>> XErrorHandlerUtil class for resolution of interdependency
>>>>>>>>>>>>>> between
>>>>>>>>>>>>>> a static initialization block of XToolkit and a block
>>>>>>>>>>>>>> initializing
>>>>>>>>>>>>>> java.awt.GraphicsEnvironment singleton. Such dependency is
>>>>>>>>>>>>>> created
>>>>>>>>>>>>>> by new calls to XToolkit static methods from
>>>>>>>>>>>>>> "src/solaris/native/sun/awt/awt_GraphicsEnv.c",
>>>>>>>>>>>>>> "src/solaris/native/sun/java2d/x11/X11SurfaceData.c" files.
>>>>>>>>>>>>>> 2. Substitution of XToolkit.WITH_XERROR_HANDLER,
>>>>>>>>>>>>>> XToolkit.RESTORE_XERROR_HANDLER ... for corresponding
>>>>>>>>>>>>>> methods,
>>>>>>>>>>>>>> fields of XErrorHandlerUtil class in all places of JDK 
>>>>>>>>>>>>>> source
>>>>>>>>>>>>>> code, where they were used.
>>>>>>>>>>>>>> 3. Substitution of all found native X error handlers 
>>>>>>>>>>>>>> which are
>>>>>>>>>>>>>> set in
>>>>>>>>>>>>>> native code (awt_GraphicsEnv.c, X11SurfaceData.c,
>>>>>>>>>>>>>> GLXSurfaceData.c) for new synthetic Java error handlers.
>>>>>>>>>>>>>> 4. Removal of X error handling code used by the native error
>>>>>>>>>>>>>> handlers
>>>>>>>>>>>>>> from "solaris/native/sun/awt/awt_util.c"
>>>>>>>>>>>>>> "solaris/native/sun/awt/awt_util.h" files.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>> Anton
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 1/11/2013 3:45 PM, Anthony Petrov wrote:
>>>>>>>>>>>>>>> I'm not Jim, but as I indicated earlier my opinion is that
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> easiest way to fix this is to install the existing
>>>>>>>>>>>>>>> J2DXErrHandler()
>>>>>>>>>>>>>>> only once. That is, it is the second option listed by 
>>>>>>>>>>>>>>> you. Of
>>>>>>>>>>>>>>> course, the J2DXErrHandler needs to be updated as well to
>>>>>>>>>>>>>>> detect
>>>>>>>>>>>>>>> whether 2D code wants to use it at the moment or it must
>>>>>>>>>>>>>>> simply
>>>>>>>>>>>>>>> delegate to the previous handler (i.e. where the code
>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>> installs/uninstalls the handler, it must instead set a 
>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>> boolean flag or something.)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> While the first option (reusing the existing AWT
>>>>>>>>>>>>>>> machinery) is an
>>>>>>>>>>>>>>> interesting idea in general, I think it is complex and 
>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>> require too much additional testing and bring an
>>>>>>>>>>>>>>> unjustified risk
>>>>>>>>>>>>>>> to the solution for such a basic problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 1/11/2013 14:44, Anton Litvinov wrote:
>>>>>>>>>>>>>>>> Hello Jim,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank you very much for the review and provision of a new
>>>>>>>>>>>>>>>> idea of
>>>>>>>>>>>>>>>> a solution. Elimination of the logic, which sets/unsets
>>>>>>>>>>>>>>>> J2DXErrHandler() for each call "XShmAttach(awt_display,
>>>>>>>>>>>>>>>> &shminfo))" should effectively resolve the issue, but
>>>>>>>>>>>>>>>> only in
>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>> if all other native error handlers, which were set by the
>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>> function "XSetErrorHandler()" in JDK or in any external
>>>>>>>>>>>>>>>> library,
>>>>>>>>>>>>>>>> observe the rule of relaying of all events, which are not
>>>>>>>>>>>>>>>> relative
>>>>>>>>>>>>>>>> to them, to the previously saved error handlers.
>>>>>>>>>>>>>>>> Otherwise an
>>>>>>>>>>>>>>>> error generated during "XShmAttach" function call will
>>>>>>>>>>>>>>>> not be
>>>>>>>>>>>>>>>> handled by J2DXErrHandler().
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Could you answer the following question. By setting
>>>>>>>>>>>>>>>> J2DXErrHandler() only once and forever do you mean usage
>>>>>>>>>>>>>>>> of AWT
>>>>>>>>>>>>>>>> global event handler "static int
>>>>>>>>>>>>>>>> ToolkitErrorHandler(Display *
>>>>>>>>>>>>>>>> dpy, XErrorEvent * event)" from
>>>>>>>>>>>>>>>> "src/solaris/native/sun/xawt/XlibWrapper.c" with Java
>>>>>>>>>>>>>>>> synthetic
>>>>>>>>>>>>>>>> handlers or creation of another global native error
>>>>>>>>>>>>>>>> handler with
>>>>>>>>>>>>>>>> J2DXErrHandler as native synthetic handler?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>> Anton
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 1/10/2013 5:44 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>> I think I'd rather see some way to prevent double-adding
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> handler in the first place as well. Since it is only
>>>>>>>>>>>>>>>>> ever used
>>>>>>>>>>>>>>>>> on errors I also think it is OK to set it once and 
>>>>>>>>>>>>>>>>> leave it
>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>> forever...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 1/9/13 8:08 AM, Anthony Petrov wrote:
>>>>>>>>>>>>>>>>>> Hi Anton et al.,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If I read the description of the bug correctly,
>>>>>>>>>>>>>>>>>> specifically
>>>>>>>>>>>>>>>>>> this part:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The problem occurs, if another thread (for example, GTK
>>>>>>>>>>>>>>>>>>> thread) is
>>>>>>>>>>>>>>>>>>> doing the same sort of thing concurrently. This can
>>>>>>>>>>>>>>>>>>> lead to
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> following situation.
>>>>>>>>>>>>>>>>>>> JVM thread: Sets J2DXErrHandler(), saves
>>>>>>>>>>>>>>>>>>> ANY_PREVIOUS_HANDLER as
>>>>>>>>>>>>>>>>>>> previous GTK thread: Sets some GTK_HANDLER, saves
>>>>>>>>>>>>>>>>>>> J2DXErrHandler() as previous JVM thread: Restores
>>>>>>>>>>>>>>>>>>> ANY_PREVIOUS_HANDLER GTK thread: Restores
>>>>>>>>>>>>>>>>>>> J2DXErrHandler() JVM
>>>>>>>>>>>>>>>>>>> thread: Sets J2DXErrHandler(), saves 
>>>>>>>>>>>>>>>>>>> J2DXErrHandler() as
>>>>>>>>>>>>>>>>>>> previous
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is obvious that at this final step 2D is in an
>>>>>>>>>>>>>>>>>> inconsistent
>>>>>>>>>>>>>>>>>> state. We
>>>>>>>>>>>>>>>>>> don't expect to replace our own error handler (and it
>>>>>>>>>>>>>>>>>> shouldn't
>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>> been there in the first place).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I realize that the fix you propose works around this
>>>>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>>>> But this
>>>>>>>>>>>>>>>>>> doesn't look like an ideal solution to me.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> BTW, IIRC, in JDK7 (and 6?) we decided to set the
>>>>>>>>>>>>>>>>>> actual X11
>>>>>>>>>>>>>>>>>> error
>>>>>>>>>>>>>>>>>> handler only once and never replace it. All the rest of
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> push_handler/pop_handler logic is now located in Java
>>>>>>>>>>>>>>>>>> code (see
>>>>>>>>>>>>>>>>>> XToolkit.SAVED_ERROR_HANDLER() and the surrounding
>>>>>>>>>>>>>>>>>> logic). I
>>>>>>>>>>>>>>>>>> believe
>>>>>>>>>>>>>>>>>> that we should somehow share this machinery with the 2D
>>>>>>>>>>>>>>>>>> code to
>>>>>>>>>>>>>>>>>> avoid
>>>>>>>>>>>>>>>>>> this sort of problems. Though I'm not sure if this will
>>>>>>>>>>>>>>>>>> eliminate this
>>>>>>>>>>>>>>>>>> exact issue.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2D/AWT folks: any other thoughts?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 12/29/2012 17:44, Anton Litvinov wrote:
>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please review the following fix for a bug.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Bug:
>>>>>>>>>>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005607 
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8005607
>>>>>>>>>>>>>>>>>>> Webrev:
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8005607/webrev.00
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The bug consists in a crash which is caused by a stack
>>>>>>>>>>>>>>>>>>> overflow
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> the reason of an infinite recursion in AWT native
>>>>>>>>>>>>>>>>>>> function
>>>>>>>>>>>>>>>>>>> J2DXErrHandler() under certain circumstances on 32-bit
>>>>>>>>>>>>>>>>>>> Linux
>>>>>>>>>>>>>>>>>>> OS. The
>>>>>>>>>>>>>>>>>>> fix is based on introduction of the logic, which 
>>>>>>>>>>>>>>>>>>> detects
>>>>>>>>>>>>>>>>>>> indirect
>>>>>>>>>>>>>>>>>>> recursive calls to J2DXErrHandler() by means of a 
>>>>>>>>>>>>>>>>>>> simple
>>>>>>>>>>>>>>>>>>> counter, to
>>>>>>>>>>>>>>>>>>> J2DXErrHandler() native function. Such a solution
>>>>>>>>>>>>>>>>>>> requires
>>>>>>>>>>>>>>>>>>> minimum
>>>>>>>>>>>>>>>>>>> code changes, does not alter the handler's code
>>>>>>>>>>>>>>>>>>> significantly
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> eliminates this bug.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Adding 2d-dev at openjdk.java.net e-mail alias to the
>>>>>>>>>>>>>>>>>>> list of
>>>>>>>>>>>>>>>>>>> recipients
>>>>>>>>>>>>>>>>>>> of this letter, because the edited function's name is
>>>>>>>>>>>>>>>>>>> related
>>>>>>>>>>>>>>>>>>> to Java
>>>>>>>>>>>>>>>>>>> 2D area of JDK, despite of the fact that the edited
>>>>>>>>>>>>>>>>>>> file is
>>>>>>>>>>>>>>>>>>> located in
>>>>>>>>>>>>>>>>>>> AWT directory.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>>>>> Anton
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>



From james.graham at oracle.com  Wed Apr 24 17:38:36 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 24 Apr 2013 10:38:36 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: 
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
	
	
	<5175A611.9080004@oracle.com>
	
	<5177345D.4060408@oracle.com>
	
Message-ID: <5178189C.1050209@oracle.com>

Hi Laurent,

On 4/24/13 1:59 AM, Laurent Bourg?s wrote:
>     Originally the version that was used in embedded used RLE because it
>     stored the results in the shape itself.  On desktop I never found
>     that to be a necessary optimization especially because it actually
>     wastes memory for no gain during animations, but that was why they
>     used RLE as a storage format.  Would it speed up the code to use a
>     different storage format?
>
>
> Maybe it could be a very good idea: compressing alpha array to RLE and
> then decompressing it to fill byte[] tile array seems a bad idea.
> However, keeping RLE encoding may help having smaller arrays to store a
> complete tile line as I want: width = 4096 (or more) x height = 32.

Or storing the crossings more directly.  It's a little obtuse to go from 
crossings to a 1D linear array of alpha deltas to RLE alphas to alphas. 
  For one thing, the crossings were sort of compact and then they got 
flattened into the deltas and then the RLE part has to do a linear 
search to compute the run lengths.  It would seem that it would be 
smaller and faster to do a more direct "crossing to RLE" step or just 
storing the crossings themselves (which are very analogous to RLE 
anyway), and then generating the tile directly from the packed stored 
crossings.

>     Also, in the version we use in JavaFX we removed the tiling
>     altogether and return one alpha array for the entire rasterization.
>       We might consider doing that for this code as well if it allows us
>     to get rid of Ductus - it was a Ductus design constraint that forced
>     the tiling (it was again based on the expected size of the hardware
>     AA engine)...
>
>
> I think tiling is still interesting as such small arrays stay in the cpu
> cache ! however, I could try tuning the tile width to be larger (256x32)
> instead of (32x32 tiles) ...

An issue with that is that there are some hard-coded pieces of the HW 
rasterizers that expect a 32x32 tile and would need to be rewritten to 
adjust to different tile sizes.  Once they are fixed then it might make 
sense to generate tiles by multiples of scanlines and dynamically 
determine the horizontal size on the fly depending on the shape being 
rasterized.  If you rasterize a shape that is 260 pixels wide then your 
256x32 tile would involve way more up-and-down in the pipeline than a 
512x16.  It might be better to have a 4K tile and then have the 
dimensions be W x (4K/W) and have the rendering loops allow an arbitrary 
tile size...

> Finally,
> Who could help me working on pisces ? Could we form a tiger team ?
> or at least could denis and you have some time to help me ?

It would be great to have a tiger team, but I'm not full-time on Java2D 
any more and Denis was only working on it during an internship so I'm 
not sure what he is up to now.

We have a "graphics-rasterizer" mailing list/project that was created to 
come up with an OS alternative to Ductus for OpenJDK.  It went silent 
when we got the first version of Pisces in and so that project has 
technically been finished.  If we can get a group of more than, well, 
you working and me tossing out suggestions then we can discuss if we 
want to revive that group or just continue on here...

			...jim


From james.graham at oracle.com  Wed Apr 24 18:22:40 2013
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 24 Apr 2013 11:22:40 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: 
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
	
	
	<5175A611.9080004@oracle.com>
	
	<5177345D.4060408@oracle.com>
	
Message-ID: <517822F0.4040800@oracle.com>

On 4/24/13 1:59 AM, Laurent Bourg?s wrote:
> Jim,
>
> First, here are both updated webrev and benchmark results:
> - results: http://jmmc.fr/~bourgesl/share/java2d-pisces/patch_opt_night.log
> - webrev: http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-2/

Some comments on the webrev:

- This caching of pipeline data in SG2D is a new precedent and I'm wary 
of it for a couple of reasons:
     - It gets tricky to satisfy all pipelines using that kind of technique
     - It breaks encapsulation, but at least it is isolated to internal code
     - SG2D will need to deal with the new field in clone().
     - Rendering a hierarchy of Swing objects uses clone() a lot so 
caching storage in SG2D may not help much in that case and thread local 
may be more of a win
- Thread local storage doesn't really have those issues
     - It's only used if that pipeline is used
     - No encapsulation issues
     - Don't need to modify clone() and it will work across clones

- Curve iterator uses auto-boxing, is that causing any churn?
- RenderingEngine may want to provide "forwarding methods" for Ductus as 
a temporary solution until we fix Ductus to be aware of the new signatures
- new constants in Dasher were moved out of the class they are used from...?
- Why get rid of the final modifiers in Dasher?  Was it not as effective 
as copying to local variables?  Note that the manual copying to local 
variables is prone to maintenance issues if someone inserts a method 
call in a block where the fields are stale.
- PRE.pathTo() could still be static, no?  Also, it would be nice to 
make this change to the existing RE helper method directly (and possibly 
provide a backwards compatibility method with the old argument list that 
simply forwards with a "new float[6]").
- Perhaps it is time to get rid of the try/catch pairs in PTG.getAlpha() 
entirely?
- When you have a field cached in a local variable and you compute a new 
value for it, then "field = var = ..." is probably better than "var = 
field = ..." since the latter implies that the answer gets stored in the 
field and then read back which is an extra memory operation.  I noticed 
this in a couple of places in Renderer, but I know I saw the local 
variable caching in other files as well.

- A lot of undoing of some very carefully planned indentation and code 
alignment issues.  Auto-formatting is evil... ;)
- A personal rant - I'm a big fan of the { on a line by itself if it 
follows an indented line-continued method declaration or control 
statement.  It helps the eye quickly find the start of the body because 
it stands out.  Your autoformatting got rid of a bunch of those and I 
made a frowny face... :(  (It may not be true to the JDK code style 
guidelines, but we've been using that style throughout the 2D code for 
years...)

- We switched to a new "within" technique in the JavaFX version of 
Pisces based upon this paper:
 
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm

The C version of the implementation in that paper is:

// Usable AlmostEqual function
// See 
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
jboolean Helpers_withinULP(const jfloat A, const jfloat B, const int 
maxUlps) {
     // Make sure maxUlps is non-negative and small enough that the
     // default NAN won't compare as equal to anything.
//    assert(maxUlps > 0 && maxUlps < 4 * 1024 * 1024);
     jint aInt, bInt;

     // Make aInt lexicographically ordered as a twos-complement int
     // This cast can induce "false positive" warnings from various 
compilers
     // or bug checking tools, but is correct as sizeof(jint) == 
sizeof(jfloat)
     aInt = *((jint *) &A);
     if (aInt < 0) {
         aInt = 0x80000000 - aInt;
     }

     // Make bInt lexicographically ordered as a twos-complement int
     // This cast can induce "false positive" warnings from various 
compilers
     // or bug checking tools, but is correct as sizeof(jint) == 
sizeof(jfloat)
     bInt = *((jint *) &B);
     if (bInt < 0) {
         bInt = 0x80000000 - bInt;
     }

     // aInt,bInt are in the range [-0x7fffffff, +0x7fffffff]
     // assuming maxUlps is much smaller than 0x7fffffff
     // ( + maxUlps) will never overflow
     // ( - maxUlps) will never overflow
     if (aInt < bInt) {
         return (aInt < 0) ? aInt + maxUlps >= bInt : bInt - maxUlps <= 
aInt;
     } else {
         return (bInt < 0) ? bInt + maxUlps >= aInt : aInt - maxUlps <= 
bInt;
     }
}

It avoids multiple calls to ULP and the complexity of figuring out 
whether to use the ULP of the larger or smaller number.  The Java 
version would have to use Float.floatToIntBits() where we used funny 
pointer casting...

			...jim


From jennifer.godinez at oracle.com  Thu Apr 25 17:14:48 2013
From: jennifer.godinez at oracle.com (jennifer.godinez at oracle.com)
Date: Thu, 25 Apr 2013 17:14:48 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 8009199: Printed text become
	garbage on Mac OSX
Message-ID: <20130425171539.D363D485D3@hg.openjdk.java.net>

Changeset: b0c41789f500
Author:    jgodinez
Date:      2013-04-25 10:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/b0c41789f500

8009199: Printed text become garbage on Mac OSX
Reviewed-by: bae, prr

! src/macosx/native/sun/awt/CTextPipe.m



From volker.simonis at gmail.com  Fri Apr 26 14:02:10 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 26 Apr 2013 16:02:10 +0200
Subject: [OpenJDK 2D-Dev] Request for review [XS]: The XRender backend fails
 to render any glyphs on 64-bit Big-endian architectures
Message-ID: 

Hi,

I've found and fixed a problem of the XRender pipeline on 64-bit
Big-endian architectures which leads to the effect that all AWT/Swing
applications will run as expected but won't actually display any
character glyphs at all! This seems to be a "day-one" bug which still
exists in both, JDK7 and JDK8 but probably didn't pop up until now
because the XRender backend wasn't enabled by default. This has
however changed recently in JDK8.

Could somebody please open a bug for this issue and review the change:

http://cr.openjdk.java.net/~simonis/webrevs/webrev_xrender.v1/

The fix is small and straightforward.
You can read the full story below (or the HTML-version in the webrev
for a better reading experience).

Thank you and best regards,
Volker



Problem description

The XRender backend writes some native data-structures which have the
size of a native pointer (i.e. 32-bit on 32-bit architectures and
64-bit on 64-bit architectures) by using Unsafe.putInt(). This is of
course not safe and breaks on 64-bit Big-endian architectures like
SPARC, PPC64 or HPUX/IA64. The concrete problem is in the method
setGlyphID in src/solaris/classes/sun/font/XRGlyphCacheEntry.java:

public static void setGlyphID(long glyphInfoPtr, int id) {
    StrikeCache.unsafe.putInt(glyphInfoPtr + StrikeCache.cacheCellOffset, id);
}

which writes the offending field and in the function
Java_sun_java2d_xr_XRBackendNative_XRAddGlyphsNative in
src/solaris/native/sun/java2d/x11/XRBackendNative.c which reads this
field:

for (i=0; i < glyphCnt; i++) {
  GlyphInfo *jginfo = (GlyphInfo *) jlong_to_ptr(glyphInfoPtrs[i]);

  gid[i] = (Glyph) (0x0ffffffffL & ((unsigned long)(jginfo->cellInfo)));

Actually, they both access the cellInfo field of a GlypInfo structure
which has the size of a native pointer (see
src/share/native/sun/font/fontscalerdefs.h):

struct GlyphInfo {
    float advanceX;
    float advanceY;
    UInt16 width;
    UInt16 height;
    UInt16 rowBytes;
    UInt8 managed;
    float topLeftX;
    float topLeftY;
    void *cellInfo;
    UInt8 *image;
}

The native reader reads the field as a void* and casts it into an
unsigned long. On Big-endian architectures this shifts the integer
value which had been previously written in setGlyphID() by 32 bits to
the left such that the final 'anding' with 0x0ffffffffL will always
lead to a zero result (on Little-endian architectures there's no
problem because the 4-byte integer value lies in the 'right' half of
the 8-byte long value).

How to reproduce the problem

This finally leads to the effect that all AWT/Swing applications will
run as expected but won't actually display any character glyphs at
all! This behavior is reproducible with every JDK7 and JDK8. You just
have to set the property -Dsun.java2d.xrender=True and make sure that
the actual Xserver which displays the application window really
supports the XRender extension. Using -Dsun.java2d.xrender=True (with
capital 'T') will print a debugging line which confirms whether the
XRender pipeline will be used ('XRender pipeline enabled') or not
('Could not enable XRender pipeline').

Notice that the XRender pipeline was switched off by default in JDK7
but is currently switched on by default in JDK8. However if the
displaying X-server doesn't support XRender there's always a silent
fallback to the plain X11 rendering pipeline. So you need an XRender
capable X server to reproduce this problem.

How to fix the problem

Fixing the problem is easy: we just have to replace the offending
Unsafe.putInt()/Unsafe.getInt() accesses with corresponding
Unsafe.putAddress()/Unsafe.getAddress() calls. These routines
write/read 4 byte in 32-bit VMs and 8 byte on 64-bit VMs (actually
they read/write Unsafe.addressSize() bytes which corresponds to the
mentioned values).

Other cleanups in the patch

Once I've fixed the problem, I've also cleaned up several other
occurrences of the following pattern:

long pixelDataAddress;
if (StrikeCache.nativeAddressSize == 4) {
    pixelDataAddress = 0xffffffff &
StrikeCache.unsafe.getInt(glyphInfoPtr + StrikeCache.pixelDataOffset);
} else {
    pixelDataAddress = StrikeCache.unsafe.getLong(glyphInfoPtr +
StrikeCache.pixelDataOffset);
}
long pixelDataAddress = StrikeCache.unsafe.getAddress(glyphInfoPtr +
StrikeCache.pixelDataOffset);

The intention of this code is to load a native pointer and store it
into a Java long variable. On 32-bit architectures it uses
Unsafe.getInt() to read the value and masks the result with 0xffffffff
after converting it into a Java long value (which is actually the same
as doing a zero-extension of a 32-bit value during the conversion into
a 64-bit value). On 64-bit architectures it simply uses
Unsafe.getLong() to read the value.

The previous code can be simplified into a single expression by always
using Unsafe.getAddress():

long pixelDataAddress = StrikeCache.unsafe.getAddress(glyphInfoPtr +
StrikeCache.pixelDataOffset);

because Unsafe.getAddress() does exactly the same thing: it reads a
native pointer and returns it as a Java long value. In the case where
the native pointer is less than 64 bits wide, it is extended as an
unsigned number to a Java long (see JavaDoc of
sun.misc.Unsafe.getAddress()).

I've also simplified the following line in the function
Java_sun_java2d_xr_XRBackendNative_XRAddGlyphsNative in
src/solaris/native/sun/java2d/x11/XRBackendNative.c:

-      gid[i] = (Glyph) (0x0ffffffffL & ((unsigned long)(jginfo->cellInfo)));
+      // 'jginfo->cellInfo' is of type 'void*' (see definition of
'GlyphInfo' in fontscalerdefs.h)
+      // 'Glyph' is typedefed to 'unsigned long' (see
http://www.x.org/releases/X11R7.7/doc/libXrender/libXrender.txt)
+      // Maybe we should assert that (sizeof(void*) == sizeof(Glyph)) ?
+      gid[i] = (Glyph) (jginfo->cellInfo);

because Glyph is typedefed to unsigned long anyway. The
'zero-extension' of the result is unnecessary as well because we're
actually reading an integer value here and not a pointer.


From patrick at reini.net  Mon Apr 29 04:39:15 2013
From: patrick at reini.net (Patrick Reinhart)
Date: Mon, 29 Apr 2013 06:39:15 +0200
Subject: [OpenJDK 2D-Dev] Fix proposal for 9001948:
	UnixPrintServiceLookup not returning consistent values
In-Reply-To: <5176BD48.6060704@oracle.com>
References: <921DCFDE-B4B9-4E51-A95E-6439111A7AC4@reini.net>
	<1366229461.2858.4.camel@wsccuw01.ccuw.ch>
	
	<5175A7F5.6070208@oracle.com>
	<7ED39034-6E81-4274-89F1-CBC9B15321AE@reini.net>
	<5176B668.7040405@oracle.com> <5176BD48.6060704@oracle.com>
Message-ID: <2A33148C-51AF-4E70-8138-E9383F634C0F@reini.net>

Hi Jennifer,

Had you got already the time to confirm the problem?

Cheers Patrick

Am 23.04.2013 um 18:56 schrieb Jennifer Godinez :

> Hi Phil,
> 
> I haven't confirmed this.  I was about to ask for the program but now I see it is included in the webrev.  I'll let you know.
> 
> Jennifer
> 


From bourges.laurent at gmail.com  Mon Apr 29 16:34:27 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Mon, 29 Apr 2013 18:34:27 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: <5178189C.1050209@oracle.com>
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
	
	
	<5175A611.9080004@oracle.com>
	
	<5177345D.4060408@oracle.com>
	
	<5178189C.1050209@oracle.com>
Message-ID: 

Jim,

Sorry for the delay: I was busy on reworking the tile generation to cache
only a single line of tiles: it allows me to have ROWAARLE[32][] and
touchedTile a 1d array.

I simply do the rendering when nextTile() detects a tile line end !

Now it is working and the thread local cache is smaller: 32 x 4096 ~ 512k
for rowAARLE.

I think less memory is wasted and such arrays best fit into cpu cache.

Next step could be to use directly alpha data instead of RLE encoding /
decoding ...

More details asap

Laurent

Le 24 avr. 2013 19:38, "Jim Graham"  a ?crit :
>
> Hi Laurent,
>
>
> On 4/24/13 1:59 AM, Laurent Bourg?s wrote:
>>
>>     Originally the version that was used in embedded used RLE because it
>>     stored the results in the shape itself.  On desktop I never found
>>     that to be a necessary optimization especially because it actually
>>     wastes memory for no gain during animations, but that was why they
>>     used RLE as a storage format.  Would it speed up the code to use a
>>     different storage format?
>>
>>
>> Maybe it could be a very good idea: compressing alpha array to RLE and
>> then decompressing it to fill byte[] tile array seems a bad idea.
>> However, keeping RLE encoding may help having smaller arrays to store a
>> complete tile line as I want: width = 4096 (or more) x height = 32.
>
>
> Or storing the crossings more directly.  It's a little obtuse to go from
crossings to a 1D linear array of alpha deltas to RLE alphas to alphas.
 For one thing, the crossings were sort of compact and then they got
flattened into the deltas and then the RLE part has to do a linear search
to compute the run lengths.  It would seem that it would be smaller and
faster to do a more direct "crossing to RLE" step or just storing the
crossings themselves (which are very analogous to RLE anyway), and then
generating the tile directly from the packed stored crossings.
>
>
>>     Also, in the version we use in JavaFX we removed the tiling
>>     altogether and return one alpha array for the entire rasterization.
>>       We might consider doing that for this code as well if it allows us
>>     to get rid of Ductus - it was a Ductus design constraint that forced
>>     the tiling (it was again based on the expected size of the hardware
>>     AA engine)...
>>
>>
>> I think tiling is still interesting as such small arrays stay in the cpu
>> cache ! however, I could try tuning the tile width to be larger (256x32)
>> instead of (32x32 tiles) ...
>
>
> An issue with that is that there are some hard-coded pieces of the HW
rasterizers that expect a 32x32 tile and would need to be rewritten to
adjust to different tile sizes.  Once they are fixed then it might make
sense to generate tiles by multiples of scanlines and dynamically determine
the horizontal size on the fly depending on the shape being rasterized.  If
you rasterize a shape that is 260 pixels wide then your 256x32 tile would
involve way more up-and-down in the pipeline than a 512x16.  It might be
better to have a 4K tile and then have the dimensions be W x (4K/W) and
have the rendering loops allow an arbitrary tile size...
>
>
>> Finally,
>> Who could help me working on pisces ? Could we form a tiger team ?
>> or at least could denis and you have some time to help me ?
>
>
> It would be great to have a tiger team, but I'm not full-time on Java2D
any more and Denis was only working on it during an internship so I'm not
sure what he is up to now.
>
> We have a "graphics-rasterizer" mailing list/project that was created to
come up with an OS alternative to Ductus for OpenJDK.  It went silent when
we got the first version of Pisces in and so that project has technically
been finished.  If we can get a group of more than, well, you working and
me tossing out suggestions then we can discuss if we want to revive that
group or just continue on here...
>
>                         ...jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jennifer.godinez at oracle.com  Mon Apr 29 17:02:55 2013
From: jennifer.godinez at oracle.com (jennifer.godinez at oracle.com)
Date: Mon, 29 Apr 2013 17:02:55 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk8/2d/jdk: 8005302: [findbugs] public
	methods return internal	arrays; may be private
Message-ID: <20130429170349.255EC4869D@hg.openjdk.java.net>

Changeset: f4aa34a7a44d
Author:    jchen
Date:      2013-04-29 10:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/2d/jdk/rev/f4aa34a7a44d

8005302: [findbugs] public methods return internal arrays; may be private
Reviewed-by: bae, prr

! src/share/classes/sun/java2d/pipe/AAShapePipe.java



From jennifer.godinez at oracle.com  Mon Apr 29 18:51:49 2013
From: jennifer.godinez at oracle.com (Jennifer Godinez)
Date: Mon, 29 Apr 2013 11:51:49 -0700
Subject: [OpenJDK 2D-Dev] Fix proposal for 9001948:
 UnixPrintServiceLookup not returning consistent values
In-Reply-To: <2A33148C-51AF-4E70-8138-E9383F634C0F@reini.net>
References: <921DCFDE-B4B9-4E51-A95E-6439111A7AC4@reini.net>
	<1366229461.2858.4.camel@wsccuw01.ccuw.ch>
	
	<5175A7F5.6070208@oracle.com>
	<7ED39034-6E81-4274-89F1-CBC9B15321AE@reini.net>
	<5176B668.7040405@oracle.com> <5176BD48.6060704@oracle.com>
	<2A33148C-51AF-4E70-8138-E9383F634C0F@reini.net>
Message-ID: <517EC145.5080504@oracle.com>

Yes I have and dicussed with Phil.  It looks pretty good but there may 
be a safer way to fix it since the fix is still using lpc/lpstat 
commands for CUPS.  Also, the regression test should be modified to use 
non internal package.  Phil will give his input on this too.

Jennifer

On 4/28/2013 9:39 PM, Patrick Reinhart wrote:
> Hi Jennifer,
>
> Had you got already the time to confirm the problem?
>
> Cheers Patrick
>
> Am 23.04.2013 um 18:56 schrieb Jennifer Godinez :
>
>> Hi Phil,
>>
>> I haven't confirmed this.  I was about to ask for the program but now I see it is included in the webrev.  I'll let you know.
>>
>> Jennifer
>>



From patrick at reini.net  Mon Apr 29 18:59:22 2013
From: patrick at reini.net (Patrick Reinhart)
Date: Mon, 29 Apr 2013 20:59:22 +0200
Subject: [OpenJDK 2D-Dev] Fix proposal for 9001948:
 UnixPrintServiceLookup not returning consistent values
In-Reply-To: <517EC145.5080504@oracle.com>
References: <921DCFDE-B4B9-4E51-A95E-6439111A7AC4@reini.net>
	<1366229461.2858.4.camel@wsccuw01.ccuw.ch>
	
	<5175A7F5.6070208@oracle.com>
	<7ED39034-6E81-4274-89F1-CBC9B15321AE@reini.net>
	<5176B668.7040405@oracle.com> <5176BD48.6060704@oracle.com>
	<2A33148C-51AF-4E70-8138-E9383F634C0F@reini.net>
	<517EC145.5080504@oracle.com>
Message-ID: <517EC30A.3010409@reini.net>

Hi Jennifer,

I left the existing commands as they where because I'm did not want to 
change anything as a rookie (the existing change is already not changing 
quit a bit) At least I tested it on my Mac to get the System V/Mac part 
verified...

I'm looking forward to read from the next steps...

Patrick


On 04/29/2013 08:51 PM, Jennifer Godinez wrote:
> Yes I have and dicussed with Phil.  It looks pretty good but there may 
> be a safer way to fix it since the fix is still using lpc/lpstat 
> commands for CUPS.  Also, the regression test should be modified to 
> use non internal package.  Phil will give his input on this too.
>
> Jennifer




From bourges.laurent at gmail.com  Tue Apr 30 16:29:11 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Tue, 30 Apr 2013 18:29:11 +0200
Subject: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and
 Memory enhancements
In-Reply-To: <517822F0.4040800@oracle.com>
References: 
	
	
	<516DBFBF.20504@oracle.com>
	
	
	
	<5175A611.9080004@oracle.com>
	
	<5177345D.4060408@oracle.com>
	
	<517822F0.4040800@oracle.com>
Message-ID: 

Jim,

here is the latest webrev:
http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-3/

I tried to revert some syntax mistakes (indentation, moved constants +
cleanup) : code cleanup is still in progress;
so please don't have a frawny face while looking at the code!

I fixed also Ductus and Jules rendering engines (TileState added in
interface)

In this patch, I modified the rowAARLE[][] array to only contain a single
tile line [32][4096] (512K). Each line is quite big already because I want
to store there the alpha data instead of RLE values:
RLE values are very interesting for horizontal lines but for dashed lines
it becomes bigger than alpha data. For example a dashed line [2-1] will
produce many segments that will be encoding like [01][x2]...

I have few questions regarding renderer edge handling and float ceil calls:
    private void addLine(float x1, float y1, float x2, float y2) {
...
        // LBO: why ceil ie upper integer ?
        final int firstCrossing = Math.max(ceil(y1), boundsMinY); // upper
integer
        final int lastCrossing  = Math.min(ceil(y2), boundsMaxY); // upper
integer

=> firstCrossing / lastCrossing should use lower and upper integer values
(rounding issues) ?

    boolean endRendering() {
        // TODO: perform shape clipping to avoid dealing with segments out
of bounding box

        // Ensure shape edges are within bbox:
        if (edgeMinX > edgeMaxX || edgeMaxX < 0f) {
            return false; // undefined X bounds or negative Xmax
        }
        if (edgeMinY > edgeMaxY || edgeMaxY < 0f) {
            return false; // undefined Y bounds or negative Ymax
        }

        // why use upper integer for edge min values ?
=> Here is the question: why use ceil instead of floor ?

        final int eMinX = ceil(edgeMinX); // upper positive int
        if (eMinX > boundsMaxX) {
            return false; // Xmin > bbox maxX
        }

        final int eMinY = ceil(edgeMinY); // upper positive int
        if (eMinY > boundsMaxY) {
            return false; // Ymin > bbox maxY
        }

        int spminX = Math.max(eMinX, boundsMinX);
        int spmaxX = Math.min(ceil(edgeMaxX), boundsMaxX); // upper
positive int
        int spminY = Math.max(eMinY, boundsMinY);
        int spmaxY = Math.min(ceil(edgeMaxY), boundsMaxY); // upper
positive int

        int pminX = spminX >> SUBPIXEL_LG_POSITIONS_X;
        int pmaxX = (spmaxX + SUBPIXEL_MASK_X) >> SUBPIXEL_LG_POSITIONS_X;
        int pminY = spminY >> SUBPIXEL_LG_POSITIONS_Y;
        int pmaxY = (spmaxY + SUBPIXEL_MASK_Y) >> SUBPIXEL_LG_POSITIONS_Y;

        // store BBox to answer ptg.getBBox():
        this.cache.init(pminX, pminY, pmaxX, pmaxY);

In PiscesCache:
    void init(int minx, int miny, int maxx, int maxy) {
...
        // LBO: why add +1 ??
        bboxX1 = maxx /* + 1 */;
        bboxY1 = maxy /* + 1 */;

=> piscesCache previously added +1 to maximum (upper loop condition y < y1)
but the pmaxX already uses ceil (+1) and (spmaxY + SUBPIXEL_MASK_Y) ensures
the last pixel is reached.

I fixed these limits to have correct rendering due to dirty rowAARLE reuse.

I think that the thread local's RendererContext is now small enough (< 1
Mb) to be used by web containers but if the number of threads is very high,
concurrent queue could help minimizing wasted memory.

Few comments:

2013/4/24 Jim Graham 

> On 4/24/13 1:59 AM, Laurent Bourg?s wrote:
>
>> Jim,
>>
>> First, here are both updated webrev and benchmark results:
>> - results: http://jmmc.fr/~bourgesl/**share/java2d-pisces/patch_opt_**
>> night.log
>> - webrev: http://jmmc.fr/~bourgesl/**share/java2d-pisces/webrev-2/
>>
>
> Some comments on the webrev:
>
> - This caching of pipeline data in SG2D is a new precedent and I'm wary of
> it for a couple of reasons:
>     - It gets tricky to satisfy all pipelines using that kind of technique
>     - It breaks encapsulation, but at least it is isolated to internal code
>     - SG2D will need to deal with the new field in clone().
>     - Rendering a hierarchy of Swing objects uses clone() a lot so caching
> storage in SG2D may not help much in that case and thread local may be more
> of a win
> - Thread local storage doesn't really have those issues
>     - It's only used if that pipeline is used
>     - No encapsulation issues
>     - Don't need to modify clone() and it will work across clones
>

Ok nevermind, I thought first it was possible but I agree it is not a
proper solution.


> - Curve iterator uses auto-boxing, is that causing any churn?
>
No, integers are in the Integer cache.


> - RenderingEngine may want to provide "forwarding methods" for Ductus as a
> temporary solution until we fix Ductus to be aware of the new signatures
>
Done in the new patch.


> - new constants in Dasher were moved out of the class they are used
> from...?
>
To be done (TBD)


> - Why get rid of the final modifiers in Dasher?  Was it not as effective
> as copying to local variables?  Note that the manual copying to local
> variables is prone to maintenance issues if someone inserts a method call
> in a block where the fields are stale.
>
I have to fix it.


> - PRE.pathTo() could still be static, no?  Also, it would be nice to make
> this change to the existing RE helper method directly (and possibly provide
> a backwards compatibility method with the old argument list that simply
> forwards with a "new float[6]").
>
Agreed: TBD


> - Perhaps it is time to get rid of the try/catch pairs in PTG.getAlpha()
> entirely?
>
Done.


> - When you have a field cached in a local variable and you compute a new
> value for it, then "field = var = ..." is probably better than "var = field
> = ..." since the latter implies that the answer gets stored in the field
> and then read back which is an extra memory operation.  I noticed this in a
> couple of places in Renderer, but I know I saw the local variable caching
> in other files as well.
>
Fixed.

>
> - A lot of undoing of some very carefully planned indentation and code
> alignment issues.  Auto-formatting is evil... ;)
>
Sorry, I may tune netbeans formatting settings.


> - A personal rant - I'm a big fan of the { on a line by itself if it
> follows an indented line-continued method declaration or control statement.
>  It helps the eye quickly find the start of the body because it stands out.
>  Your autoformatting got rid of a bunch of those and I made a frowny
> face... :(  (It may not be true to the JDK code style guidelines, but we've
> been using that style throughout the 2D code for years...)
>
Sorry again; however I like autoformating to let me work more on the code
not on syntax / indentation.

>
> - We switched to a new "within" technique in the JavaFX version of Pisces
> based upon this paper:
>
> http://www.cygnus-software.**com/papers/comparingfloats/**
> comparingfloats.htm
>
> Good idea, but I think there is many place where float <-> int conversion
/ tests should be improved ...

Do you have any faster implementation for Math.ceil/floor ? I now use
casting 1 + (int) / (int) but I know it is only correct for positive
numbers (> 0).

I have found few bugs:
- rendering a infinite line [vertical] draws nothing: I have to do a
diagnostic ...
- clipping issues:
for very large dashed rectangle, millions of segments are emited from
dasher (x1) to stroker (x4 segments) to renderer (x4 segments).

However, I would like to add a minimal clipping algorithm but the rendering
pipeline seems to be handling affine transforms between stages:
        /*
         * Pipeline seems to be:
         *    shape.getPathIterator
         * -> inverseDeltaTransformConsumer
         * -> Dasher
         * -> Stroker
         * -> deltaTransformConsumer OR transformConsumer
         * -> pc2d = Renderer (bounding box)
         */

It is complicated to perform clipping in the Renderer and maybe to late as
a complete stroker's segment must be considered as a whole (4 segments
without caps ...).

Could you give me advices how to hack / add clipping algorithm in the
rendering pipeline (dasher / stroker / renderer) ?

Should I try to derive a bounding box for the dasher / stroker depending on
the Affine transforms ?

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: