From linuxhippy at gmail.com Mon Dec 1 15:44:22 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 1 Dec 2008 16:44:22 +0100 Subject: [OpenJDK 2D-Dev] Question about STR pipelines and Surface/SW blits Message-ID: <194f62550812010744s797f49cse59b81a47cbe7072@mail.gmail.com> Hi, I am not sure if I completly understand how getRaster/getRasInfo/Sw-Surface blits fit together: First the pipeline looks for an appropriate blit, if one can be found its used. If not, getRasInfo is called by the native loops. Because the STR pipes cover all possibible surface combinations, getRasInfo is never called. Are those assumptions right? When is SurfaceData.getRaster called, and why does't it matter that its not implemented e.g. for X11SurfaceData? Are there any disadvantages by relying on getRasInfo compared to explicit blit loops? Dmitri told me that it was done this way to avoid threading issues, however my pipeline is synchronous anyway, only generating X protocol on the java side ... and the getRasInfo code is already written ;) When getRasInfo is called, I intend to: 1. Call into Java code 2. Grab a lock on the protocoll buffer 3. Flush all pending operations (which is a Java->C call) 4. return to getRasInfo and continue (which calls XSync if needed). Should I expect problems with design? The STR pipelines could have used quite the same mechanism, why wasn't it done? Thanks, Clemens From roman.kennke at aicas.com Tue Dec 2 19:46:16 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 02 Dec 2008 20:46:16 +0100 Subject: [OpenJDK 2D-Dev] Question about STR pipelines and Surface/SW blits In-Reply-To: <194f62550812010744s797f49cse59b81a47cbe7072@mail.gmail.com> References: <194f62550812010744s797f49cse59b81a47cbe7072@mail.gmail.com> Message-ID: <1228247176.6367.59.camel@moonlight> Hi Clemens, > I am not sure if I completly understand how > getRaster/getRasInfo/Sw-Surface blits fit together: > > First the pipeline looks for an appropriate blit, if one can be found > its used. If not, getRasInfo is called by the native loops. > Because the STR pipes cover all possibible surface combinations, > getRasInfo is never called. > Are those assumptions right? AFAICS (I'm not the expert here, but I'm digging in this code right now), GetRasInfo() (and the other SurfaceData.h function pointers) is called whenever a native render loop needs to access pixel data of the surface. This happens when a pipeline doesn't have certain graphics primitive for that surface overridden, usually happens for complex stuff like compositing, drawing with complex clip, etc. > When is SurfaceData.getRaster called, and why does't it matter that > its not implemented e.g. for X11SurfaceData? AFAIK, it is called if there are no native ops registered, then as a last resort the loops try to grab the raster and get the pixel data out of this. > Are there any disadvantages by relying on getRasInfo compared to > explicit blit loops? Performance. If you can implement a certain operation by an HW accelerated blit, then it's most likely faster than letting the SW loops render the stuff. /Roman > Dmitri told me that it was done this way to avoid threading issues, > however my pipeline is synchronous anyway, only generating X protocol > on the java side ... and the getRasInfo code is already written ;) > > When getRasInfo is called, I intend to: > 1. Call into Java code > 2. Grab a lock on the protocoll buffer > 3. Flush all pending operations (which is a Java->C call) > 4. return to getRasInfo and continue (which calls XSync if needed). > > Should I expect problems with design? > The STR pipelines could have used quite the same mechanism, why wasn't it done? > > Thanks, Clemens -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From linuxhippy at gmail.com Tue Dec 2 20:09:53 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 2 Dec 2008 21:09:53 +0100 Subject: [OpenJDK 2D-Dev] Question about STR pipelines and Surface/SW blits In-Reply-To: <1228247176.6367.59.camel@moonlight> References: <194f62550812010744s797f49cse59b81a47cbe7072@mail.gmail.com> <1228247176.6367.59.camel@moonlight> Message-ID: <194f62550812021209o258daf79m4c145aa499af6c5e@mail.gmail.com> Hi Roman, > AFAICS (I'm not the expert here, but I'm digging in this code right > now), GetRasInfo() (and the other SurfaceData.h function pointers) is > called whenever a native render loop needs to access pixel data of the > surface. This happens when a pipeline doesn't have certain graphics > primitive for that surface overridden, usually happens for complex stuff > like compositing, drawing with complex clip, etc. What I wonder is how the STR pipelines handle fallbacks, for exmaple the OpenGL pipeline does not have getRasInfo nor getRaster implemented. The only thing it has are Surface->SW blits, so it seems they are used for fallbacks, at least thats what I guess. I wonder where the descission is done which path to go... I wonder wether there are drawbacks when only implementing the native getRasInfo as currently done by the X11 pipeline. > AFAIK, it is called if there are no native ops registered, then as a > last resort the loops try to grab the raster and get the pixel data out > of this. Ah, good to know, thanks :) Thanks, Clemens From jennifer.godinez at sun.com Thu Dec 4 18:16:40 2008 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Thu, 04 Dec 2008 18:16:40 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6587245: Import declaration not used in sun.print.* Message-ID: <20081204181700.DBE00DFB7@hg.openjdk.java.net> Changeset: c8eea39734e8 Author: jgodinez Date: 2008-12-04 10:05 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c8eea39734e8 6587245: Import declaration not used in sun.print.* Reviewed-by: tdv, prr ! src/share/classes/javax/print/Doc.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/DocPrintJob.java ! src/share/classes/javax/print/MultiDocPrintService.java ! src/share/classes/javax/print/PrintServiceLookup.java ! src/share/classes/javax/print/attribute/URISyntax.java ! src/share/classes/javax/print/event/PrintServiceAttributeEvent.java ! src/share/classes/sun/print/PSPathGraphics.java ! src/share/classes/sun/print/PrintJobAttributeException.java ! src/share/classes/sun/print/SunMinMaxPage.java ! src/share/classes/sun/print/SunPageSelection.java From Phil.Race at Sun.COM Thu Dec 4 18:46:05 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 04 Dec 2008 10:46:05 -0800 Subject: [OpenJDK 2D-Dev] JVM Crash: printing character \u0DDD in Swing app In-Reply-To: <64efa1ba0811270700j1e925776gccf8ab0ef0ffa711@mail.gmail.com> References: <64efa1ba0811270700j1e925776gccf8ab0ef0ffa711@mail.gmail.com> Message-ID: <4938256D.7030504@sun.com> I reproduced this on JDK 1.6 update 10. The crash is in the ICU layout library which is the same in JDk7 and OpenJDk etc. Layout is invoked because this is an Indic language (Sinhalese) character. I'm not sure what's going on. I don't think its specific to Ubuntu, although I didn't see a crash on anything other than Linux, nor do I think its specific to any particular font. I think its in the Indic character processing. I'll forward the test case to the ICU layout maintainer. -phil. Patrick Wright wrote: > Hi > > First--if necessary, am glad to file a bug for this, but wanted to > check and see if there was something I'm missing. > > In trying to render a table of characters using their Unicode > identifiers, I found that the character \u0DDD crashes my JVM as soon > as it is rendered to a Swing component. I'm not particularly > interested in that character--I am just trying to print out different > characters in different fonts to easily track which glyphs are > available per font. I found this by accident. I'm writing to this list > as I suspect (but don't know) that it may be an issue with the font > system. > > java -version > java version "1.6.0_10" > Java(TM) SE Runtime Environment (build 1.6.0_10-b33) > Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) > > Ubuntu 8.10 > uname -r > 2.6.27-7-generic > > Small app that shows the problem: > import javax.swing.*; > import javax.swing.border.LineBorder; > import java.awt.*; > import java.awt.event.ActionEvent; > > public class TestChar { > public static void main(String[] args) { > SwingUtilities.invokeLater(new Runnable() { > public void run() { > new TestChar().run(); > } > }); > } > > private void run() { > JFrame frame = new JFrame("Test Character"); > frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > JPanel panel = new JPanel(); > final JLabel label = new JLabel("(empty)"); > label.setSize(400, 100); > label.setBorder(new LineBorder(Color.black)); > JButton button = new JButton("Set Char x0DDD"); > button.addActionListener(new AbstractAction() { > public void actionPerformed(ActionEvent actionEvent) { > label.setText(Character.toString('\u0DDD')); > } > }); > panel.add(button); > panel.add(label); > > frame.getContentPane().add(panel); > frame.pack(); > frame.setVisible(true); > } > } > > Run this, then click the button. On my Ubuntu system, clicking the > button causes an immediate crash of the VM. Have also tested on OS X > java -version > java version "1.6.0_07" > Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153) > Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode) > > and the VM _did not crash_. > > Output in the Ubuntu console following the crash is attached. > > If I should just file a bug for this, please let me know. > > Thanks! > Patrick > From pdoubleya at gmail.com Thu Dec 4 19:22:19 2008 From: pdoubleya at gmail.com (Patrick Wright) Date: Thu, 4 Dec 2008 20:22:19 +0100 Subject: [OpenJDK 2D-Dev] JVM Crash: printing character \u0DDD in Swing app In-Reply-To: <4938256D.7030504@sun.com> References: <64efa1ba0811270700j1e925776gccf8ab0ef0ffa711@mail.gmail.com> <4938256D.7030504@sun.com> Message-ID: <64efa1ba0812041122i3a35cd42n52a86c51afd4af3d@mail.gmail.com> Thanks for the update, Phil. The actual glyph wasn't that important to me--this came up when trying to render tables of glyphs for users looking for glyph coverage in various fonts. It would be nice to see it fixed, it's a particularly nasty crash, IMO. Regards Patrick On Thu, Dec 4, 2008 at 7:46 PM, Phil Race wrote: > I reproduced this on JDK 1.6 update 10. The crash is in the ICU layout > library > which is the same in JDk7 and OpenJDk etc. Layout is invoked because this is > an Indic language (Sinhalese) character. > > I'm not sure what's going on. I don't think its specific to Ubuntu, although > I didn't see a crash on anything other than Linux, nor do I think its > specific to any particular font. I think its in the Indic character > processing. I'll forward the test case to the ICU layout maintainer. > > -phil. > > Patrick Wright wrote: >> >> Hi >> >> First--if necessary, am glad to file a bug for this, but wanted to >> check and see if there was something I'm missing. >> >> In trying to render a table of characters using their Unicode >> identifiers, I found that the character \u0DDD crashes my JVM as soon >> as it is rendered to a Swing component. I'm not particularly >> interested in that character--I am just trying to print out different >> characters in different fonts to easily track which glyphs are >> available per font. I found this by accident. I'm writing to this list >> as I suspect (but don't know) that it may be an issue with the font >> system. >> >> java -version >> java version "1.6.0_10" >> Java(TM) SE Runtime Environment (build 1.6.0_10-b33) >> Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing) >> >> Ubuntu 8.10 >> uname -r >> 2.6.27-7-generic >> >> Small app that shows the problem: >> import javax.swing.*; >> import javax.swing.border.LineBorder; >> import java.awt.*; >> import java.awt.event.ActionEvent; >> >> public class TestChar { >> public static void main(String[] args) { >> SwingUtilities.invokeLater(new Runnable() { >> public void run() { >> new TestChar().run(); >> } >> }); >> } >> >> private void run() { >> JFrame frame = new JFrame("Test Character"); >> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> JPanel panel = new JPanel(); >> final JLabel label = new JLabel("(empty)"); >> label.setSize(400, 100); >> label.setBorder(new LineBorder(Color.black)); >> JButton button = new JButton("Set Char x0DDD"); >> button.addActionListener(new AbstractAction() { >> public void actionPerformed(ActionEvent actionEvent) { >> label.setText(Character.toString('\u0DDD')); >> } >> }); >> panel.add(button); >> panel.add(label); >> >> frame.getContentPane().add(panel); >> frame.pack(); >> frame.setVisible(true); >> } >> } >> >> Run this, then click the button. On my Ubuntu system, clicking the >> button causes an immediate crash of the VM. Have also tested on OS X >> java -version >> java version "1.6.0_07" >> Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153) >> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode) >> >> and the VM _did not crash_. >> >> Output in the Ubuntu console following the crash is attached. >> >> If I should just file a bug for this, please let me know. >> >> Thanks! >> Patrick >> > From dmitri.trembovetski at sun.com Thu Dec 4 19:27:49 2008 From: dmitri.trembovetski at sun.com (dmitri.trembovetski at sun.com) Date: Thu, 04 Dec 2008 19:27:49 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6708580: Java applications slow when EXA enabled Message-ID: <20081204192814.C0675DFD9@hg.openjdk.java.net> Changeset: 15435c60c751 Author: tdv Date: 2008-12-04 11:21 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/15435c60c751 6708580: Java applications slow when EXA enabled Reviewed-by: prr, tdv Contributed-by: ceisserer ! make/sun/awt/mapfile-mawt-vers ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c From mark at klomp.org Fri Dec 5 09:04:56 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 05 Dec 2008 10:04:56 +0100 Subject: [OpenJDK 2D-Dev] JVM Crash: printing character \u0DDD in Swing app In-Reply-To: <4938256D.7030504@sun.com> References: <64efa1ba0811270700j1e925776gccf8ab0ef0ffa711@mail.gmail.com> <4938256D.7030504@sun.com> Message-ID: <1228467896.3521.6.camel@dijkstra.wildebeest.org> Hi Phil, On Thu, 2008-12-04 at 10:46 -0800, Phil Race wrote: > I'm not sure what's going on. I don't think its specific to Ubuntu, although > I didn't see a crash on anything other than Linux, nor do I think its > specific to any particular font. I think its in the Indic character > processing. I'll forward the test case to the ICU layout maintainer. I also saw it on Fedora with the default packages, so it isn't specific to Ubuntu. What is the mailinglist for ICU that you forwarded this issue to? Thanks, Mark From Phil.Race at Sun.COM Fri Dec 5 09:11:32 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Fri, 05 Dec 2008 01:11:32 -0800 Subject: [OpenJDK 2D-Dev] JVM Crash: printing character \u0DDD in Swing app In-Reply-To: <1228467896.3521.6.camel@dijkstra.wildebeest.org> References: <64efa1ba0811270700j1e925776gccf8ab0ef0ffa711@mail.gmail.com> <4938256D.7030504@sun.com> <1228467896.3521.6.camel@dijkstra.wildebeest.org> Message-ID: <1F113920-0CB0-4CEE-8D96-2329BFEA6A22@Sun.COM> I'm not familiar with the ICU mailing lists. I just highlighted it to a couple of ICU developers, at least one of whom is on this list. -phil. On Dec 5, 2008, at 1:04 AM, Mark Wielaard wrote: > Hi Phil, > > On Thu, 2008-12-04 at 10:46 -0800, Phil Race wrote: >> I'm not sure what's going on. I don't think its specific to Ubuntu, >> although >> I didn't see a crash on anything other than Linux, nor do I think its >> specific to any particular font. I think its in the Indic character >> processing. I'll forward the test case to the ICU layout maintainer. > > I also saw it on Fedora with the default packages, so it isn't > specific > to Ubuntu. What is the mailinglist for ICU that you forwarded this > issue > to? > > Thanks, > > Mark > From mark at klomp.org Fri Dec 5 09:19:12 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 05 Dec 2008 10:19:12 +0100 Subject: [OpenJDK 2D-Dev] JVM Crash: printing character \u0DDD in Swing app In-Reply-To: <1F113920-0CB0-4CEE-8D96-2329BFEA6A22@Sun.COM> References: <64efa1ba0811270700j1e925776gccf8ab0ef0ffa711@mail.gmail.com> <4938256D.7030504@sun.com> <1228467896.3521.6.camel@dijkstra.wildebeest.org> <1F113920-0CB0-4CEE-8D96-2329BFEA6A22@Sun.COM> Message-ID: <1228468752.3521.15.camel@dijkstra.wildebeest.org> Hi Phil, On Fri, 2008-12-05 at 01:11 -0800, Phil Race wrote: > I'm not familiar with the ICU mailing lists. > I just highlighted it to a couple of ICU developers, at least one of > whom is on this list. Thanks. Just wanted to make sure I am on the right list (*) since I did see this issue also. Cheers, Mark (*) openjdk has way too many lists imho, it is pretty hard to keep in the loop, since it is too easy to miss yet another list. From Martin.vGagern at gmx.net Mon Dec 8 10:33:40 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Mon, 08 Dec 2008 11:33:40 +0100 Subject: [OpenJDK 2D-Dev] Still waiting for review Message-ID: <493CF804.6000202@gmx.net> Hi! My patches to address bug #5106550 and bug #5082756 as well as the one to correct and improve the fix for bug #6541476 are still not reviewed, not even anserwred or commented about. Im feeling pretty frustrated by this. After all, I'm donating the work I invested in fixing these issues, writing test cases, and even reviewing that latest changeset for #6541476. The way things are going so far, I won't likely do that agin, but instead simply work around issues and leave the jdk buggy as it is. You risk losing contributions. If the lack of review really is due to the fact that I only attached patches and not webrev generated HTML, tell me, and I'll try to get webrev working and some webspace allocated for this. I didn't do so yet because that involves quite some work here, because the wdiff part of webrev doesn't work out of the box for me, and because I don't see much benefit comparing webrev output over the unified diffs I sent. 5106550: http://article.gmane.org/gmane.comp.java.openjdk.2d.devel/522 5082756: http://article.gmane.org/gmane.comp.java.openjdk.2d.devel/523 6541476: http://article.gmane.org/gmane.comp.java.openjdk.2d.devel/526 Greetings, Martin von Gagern -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From mark at klomp.org Mon Dec 8 10:55:39 2008 From: mark at klomp.org (Mark Wielaard) Date: Mon, 08 Dec 2008 11:55:39 +0100 Subject: [OpenJDK 2D-Dev] Still waiting for review In-Reply-To: <493CF804.6000202@gmx.net> References: <493CF804.6000202@gmx.net> Message-ID: <1228733739.3712.6.camel@dijkstra.wildebeest.org> Hi, Same issue here as Martin. The following two patches are still waiting: http://article.gmane.org/gmane.comp.java.openjdk.2d.devel/537 http://article.gmane.org/gmane.comp.java.openjdk.2d.devel/498 > Im feeling pretty frustrated by this. After all, I'm donating the work I > invested in fixing these issues, writing test cases, and even reviewing > that latest changeset for #6541476. The way things are going so far, I > won't likely do that agin, but instead simply work around issues and > leave the jdk buggy as it is. You risk losing contributions. Martin, if you like we can use IcedTea http://icedtea.classpath.org/ as staging area for these fixes. That is what I do after testing. The above two fixes are already in IcedTea6 for a couple of months since I know other users are seeing the same bugs. That way things are at least picked up in a timely manner for the various GNU/Linux distros out there. http://icedtea.classpath.org/hg/icedtea6 Cheers, Mark From Dalibor.Topic at Sun.COM Mon Dec 8 11:16:41 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Mon, 08 Dec 2008 12:16:41 +0100 Subject: [OpenJDK 2D-Dev] Still waiting for review In-Reply-To: <1228733739.3712.6.camel@dijkstra.wildebeest.org> References: <493CF804.6000202@gmx.net> <1228733739.3712.6.camel@dijkstra.wildebeest.org> Message-ID: <493D0219.30905@Sun.COM> On 12/ 8/08 11:55 AM, Mark Wielaard wrote: > Hi, > > Same issue here as Martin. The following two patches are still waiting: > http://article.gmane.org/gmane.comp.java.openjdk.2d.devel/537 > http://article.gmane.org/gmane.comp.java.openjdk.2d.devel/498 > > >> Im feeling pretty frustrated by this. After all, I'm donating the work I >> invested in fixing these issues, writing test cases, and even reviewing >> that latest changeset for #6541476. The way things are going so far, I >> won't likely do that agin, but instead simply work around issues and >> leave the jdk buggy as it is. You risk losing contributions. >> On a side note, it'd be nice to be able to find the different patches that seem to have fallen through the cracks more easily then by testing everyone's patience by requiring repeated pings from submitter - any way we could leverage gmane or markmail to do that? cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From Igor.Nekrestyanov at Sun.COM Mon Dec 8 11:24:04 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Mon, 08 Dec 2008 14:24:04 +0300 Subject: [OpenJDK 2D-Dev] Still waiting for review In-Reply-To: <1228733739.3712.6.camel@dijkstra.wildebeest.org> References: <493CF804.6000202@gmx.net> <1228733739.3712.6.camel@dijkstra.wildebeest.org> Message-ID: <493D03D4.3060606@sun.com> Hi Mark and Martin, sorry for delay with our responses. Many of us were involved into FX prerelease activities and had to postpone some of openjdk work. My understanding of current situation with Martin's fixes is the following: - for 2 of Martin's fixes internal formal review procedure is in progress (we do review all changes and save approved webrevs and this is another reason why we ask for webrevs for contributions) Unfortunately this procedure is not public and therefore it is hard to track it status. However, it should not take long. - one of the suggested fixes actually introduces incompatibility in the behavior and such change has to be reviewed by CCC committee (this is how we call it internally, not sure what will be public name when it become public process) [My understanding of incompatibility is: metadata written by "fixed" jdk will not be parsed normally by older jdk] Andrew Brygin (who actually works on these 3 submissions) will provide more accurate details about these 3 bugs later today. I am not sure what is the current status of Mark's patches but i'll ask. Sorry again and thank you for your contribution to the project, -igor Mark Wielaard wrote: > Hi, > > Same issue here as Martin. The following two patches are still waiting: > http://article.gmane.org/gmane.comp.java.openjdk.2d.devel/537 > http://article.gmane.org/gmane.comp.java.openjdk.2d.devel/498 > > >> Im feeling pretty frustrated by this. After all, I'm donating the work I >> invested in fixing these issues, writing test cases, and even reviewing >> that latest changeset for #6541476. The way things are going so far, I >> won't likely do that agin, but instead simply work around issues and >> leave the jdk buggy as it is. You risk losing contributions. >> > > Martin, if you like we can use IcedTea http://icedtea.classpath.org/ as > staging area for these fixes. That is what I do after testing. The above > two fixes are already in IcedTea6 for a couple of months since I know > other users are seeing the same bugs. That way things are at least > picked up in a timely manner for the various GNU/Linux distros out > there. http://icedtea.classpath.org/hg/icedtea6 > > Cheers, > > Mark > > From Martin.vGagern at gmx.net Mon Dec 8 11:55:50 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Mon, 08 Dec 2008 12:55:50 +0100 Subject: [OpenJDK 2D-Dev] Still waiting for review In-Reply-To: <493D03D4.3060606@sun.com> References: <493CF804.6000202@gmx.net> <1228733739.3712.6.camel@dijkstra.wildebeest.org> <493D03D4.3060606@sun.com> Message-ID: <493D0B46.1010401@gmx.net> Hi Igor, thanks for your status update. Igor Nekrestyanov wrote: > My understanding of current situation with Martin's fixes is the following: > - for 2 of Martin's fixes internal formal review procedure is in progress > (we do review all changes and save approved webrevs and this is > another reason why we ask for webrevs for contributions) > Unfortunately this procedure is not public and therefore it is hard > to track it status. However, it should not take long. A short mail saying "Hi, I'm , I'll now start to review this and get back to you when I have questions or reached a verdict" would be a first step towards tracking that state, until more elaborate tracking tools and mechanisms become available. > - one of the suggested fixes actually introduces incompatibility in the > behavior > and such change has to be reviewed by CCC committee (this is how we > call it internally, > not sure what will be public name when it become public process) > [My understanding of incompatibility is: metadata written by "fixed" > jdk will not be parsed normally by older jdk] Thanks, I'll look at this again, see if I have improvements or additional information to add regarding this. If so, I'll use the appropriate thread. > Andrew Brygin (who actually works on these 3 submissions) will provide > more accurate details about these 3 bugs later today. Great! Looking forward to that. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From Martin.vGagern at gmx.net Mon Dec 8 12:04:36 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Mon, 08 Dec 2008 13:04:36 +0100 Subject: [OpenJDK 2D-Dev] Still waiting for review In-Reply-To: <1228733739.3712.6.camel@dijkstra.wildebeest.org> References: <493CF804.6000202@gmx.net> <1228733739.3712.6.camel@dijkstra.wildebeest.org> Message-ID: <493D0D54.5040102@gmx.net> Mark Wielaard wrote: > Martin, if you like we can use IcedTea http://icedtea.classpath.org/ as > staging area for these fixes. That is what I do after testing. The above > two fixes are already in IcedTea6 for a couple of months since I know > other users are seeing the same bugs. That way things are at least > picked up in a timely manner for the various GNU/Linux distros out > there. http://icedtea.classpath.org/hg/icedtea6 Hi Mark! Looking at the IcedTea FAQs I read "It is not a fork of the OpenJDK, and doesn't contain the OpenJDK source code". So I'm a bit surprised about the suggestion. Looking at the repository, I see a collection of patches, which seems to be the place you had in mind. While I like the idea of making my chnges available to distros even before they have been officially accepted into OpenJDK, it feels a bit like a misuse of the IcedTea project. A community-driven experimental fork would be more suitable to stage such patches imho. As acceptance into OpenJDK still is my primary goal, and as Igor's mail indicates light at the end of the tunnel in that direction, I'm inclined to rather wait for the review than invest additional effort into pushing those patches into yet another project. Still thanks for the suggestion, I'll keep it in mind and get back to that if things don't work out here. Greetings, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From Martin.vGagern at gmx.net Mon Dec 8 12:41:56 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Mon, 08 Dec 2008 13:41:56 +0100 Subject: [OpenJDK 2D-Dev] Still waiting for review In-Reply-To: <493D0219.30905@Sun.COM> References: <493CF804.6000202@gmx.net> <1228733739.3712.6.camel@dijkstra.wildebeest.org> <493D0219.30905@Sun.COM> Message-ID: <493D1614.2050703@gmx.net> Dalibor Topic wrote: > On a side note, it'd be nice to be able to find the different patches > that seem to have fallen through the cracks more easily then by > testing everyone's patience by requiring repeated pings from > submitter - any way we could leverage gmane or markmail to do that? How would you identify a patch that has "fallen through the cracks"? You could compare it to repository changesets or current state and try to see if it got applied. You could look for repository committ messages mentioning the same bug and the sender. You could try to parse messages from developers for keywords indicating a rejection. For none of this I can see any gain in using gmane or markmail, so you might as well do things on openjdk hardware, e.g. using the pipermail archives http://mail.openjdk.java.net/pipermail/2d-dev/ or by registering some mail-parsing tool as a recipient of list mails. In general when dealing with patches I prefer issue trackes with web frontends to mailing lists, for the following reasons: * users can subscribe to individual issues, not only whole lists * issues can be assigned to maintainers for review * public status tracking * easy searching for open issues If Sun has some internal tool to track issues, maybe there could be some way to automatically compare tracker and mailing list, so you can find which mailed patches have an corresponding issue already opend and which don't, and easily open issues for new patches to keep track of them internally. The combination of mailing list with patch status tracking makes me think of the Bundle BUGGY tool the bazaar developers are using: http://bundlebuggy.aaronbentley.com/ http://bundlebuggy.aaronbentley.com/help As far as I understand it, that tool tracks a mailing list, looking for patches exported by bazaar (called bundles) on the one hand and status changing commands from maintainers on the other hand. It also performs patch code coloring, a bit akin to webrev. I don't know if it would be possible to modify that tool to work with hg instead of bzr. I have the feeling that all these ideas should probably be discussed on some list other than 2d-dev, as other parts of openjdk are affected as well. If you open a corresponding thread somewhere else about this, please cc me. Greetings, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From Alexey.Ushakov at Sun.COM Mon Dec 8 12:55:48 2008 From: Alexey.Ushakov at Sun.COM (Alexey Ushakov) Date: Mon, 08 Dec 2008 15:55:48 +0300 Subject: [OpenJDK 2D-Dev] Still waiting for review In-Reply-To: <493D0B46.1010401@gmx.net> References: <493CF804.6000202@gmx.net> <1228733739.3712.6.camel@dijkstra.wildebeest.org> <493D03D4.3060606@sun.com> <493D0B46.1010401@gmx.net> Message-ID: <493D1954.60109@sun.com> Hi Martin, I'm currently looking into http://www.jroller.com/dgilbert/entry/jfreechart_and_jxlayer issue and your patch. Unfortunately we're all working in parallel on many different project, so I'm unable to dedicate all my time for this task. Currently, I did verify that your fix does solve the problem but need more time to go through all the details of pisces AA engine to be sure that everything is OK. I'll let you know about any progress on this. Best Regards, Alexey Martin von Gagern wrote: > Hi Igor, > > thanks for your status update. > > Igor Nekrestyanov wrote: > >> My understanding of current situation with Martin's fixes is the following: >> - for 2 of Martin's fixes internal formal review procedure is in progress >> (we do review all changes and save approved webrevs and this is >> another reason why we ask for webrevs for contributions) >> Unfortunately this procedure is not public and therefore it is hard >> to track it status. However, it should not take long. >> > > A short mail saying "Hi, I'm , I'll now start to review > this and get back to you when I have questions or reached a verdict" > would be a first step towards tracking that state, until more elaborate > tracking tools and mechanisms become available. > > >> - one of the suggested fixes actually introduces incompatibility in the >> behavior >> and such change has to be reviewed by CCC committee (this is how we >> call it internally, >> not sure what will be public name when it become public process) >> [My understanding of incompatibility is: metadata written by "fixed" >> jdk will not be parsed normally by older jdk] >> > > Thanks, I'll look at this again, see if I have improvements or > additional information to add regarding this. If so, I'll use the > appropriate thread. > > >> Andrew Brygin (who actually works on these 3 submissions) will provide >> more accurate details about these 3 bugs later today. >> > > Great! Looking forward to that. > > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at klomp.org Mon Dec 8 13:05:03 2008 From: mark at klomp.org (Mark Wielaard) Date: Mon, 08 Dec 2008 14:05:03 +0100 Subject: [OpenJDK 2D-Dev] Still waiting for review In-Reply-To: <493D0D54.5040102@gmx.net> References: <493CF804.6000202@gmx.net> <1228733739.3712.6.camel@dijkstra.wildebeest.org> <493D0D54.5040102@gmx.net> Message-ID: <1228741503.3712.20.camel@dijkstra.wildebeest.org> Hi Martin, On Mon, 2008-12-08 at 13:04 +0100, Martin von Gagern wrote: > Mark Wielaard wrote: > > Martin, if you like we can use IcedTea http://icedtea.classpath.org/ as > > staging area for these fixes. That is what I do after testing. The above > > two fixes are already in IcedTea6 for a couple of months since I know > > other users are seeing the same bugs. That way things are at least > > picked up in a timely manner for the various GNU/Linux distros out > > there. http://icedtea.classpath.org/hg/icedtea6 > > Looking at the IcedTea FAQs I read "It is not a fork of the OpenJDK, and > doesn't contain the OpenJDK source code". So I'm a bit surprised about > the suggestion. Looking at the repository, I see a collection of > patches, which seems to be the place you had in mind. > > While I like the idea of making my chnges available to distros even > before they have been officially accepted into OpenJDK, it feels a bit > like a misuse of the IcedTea project. A community-driven experimental > fork would be more suitable to stage such patches imho. There are forks in various degrees. IcedTea isn't really a fork, just as the ClosedJDK Sun creates from OpenJDK isn't really a fork. They just includes stuff that isn't yet in OpenJDK proper for various reasons, or stuff that extends it (like applet, webstart support, ports to various architectures, etc.) > As acceptance into OpenJDK still is my primary goal, and as Igor's mail > indicates light at the end of the tunnel in that direction, I'm inclined > to rather wait for the review than invest additional effort into pushing > those patches into yet another project. I don't really see it as yet another project. It is just a place to store patches so they aren't "falling through the cracks" as Dalibor puts it. I agree with him that it is pretty hard to keep track these days though :{ The icedtea/patches dirs now contain 100+ patches, which is indeed a bit much. But at least it makes sure that there is forward progress. > Still thanks for the suggestion, I'll keep it in mind and get back to > that if things don't work out here. I am happy to see progress also! Cheers, Mark From Alexey.Ushakov at Sun.COM Mon Dec 8 13:10:30 2008 From: Alexey.Ushakov at Sun.COM (Alexey Ushakov) Date: Mon, 08 Dec 2008 16:10:30 +0300 Subject: [OpenJDK 2D-Dev] Still waiting for review In-Reply-To: <493D1954.60109@sun.com> References: <493CF804.6000202@gmx.net> <1228733739.3712.6.camel@dijkstra.wildebeest.org> <493D03D4.3060606@sun.com> <493D0B46.1010401@gmx.net> <493D1954.60109@sun.com> Message-ID: <493D1CC6.4060001@sun.com> Hi Mark, Please, read my comments about your patch. Sorry Martin, looks like this issue isn't yours. Best Regards, Alexey Alexey Ushakov wrote: > Hi Martin, > > I'm currently looking into > http://www.jroller.com/dgilbert/entry/jfreechart_and_jxlayer > > issue and your patch. Unfortunately we're all working in parallel on > many different project, so I'm unable to dedicate all my time for this > task. Currently, I did verify that your fix does solve the problem > but need more time to go through all the details of pisces AA engine > to be sure that everything is OK. I'll let you know about any progress > on this. > > Best Regards, > Alexey > > Martin von Gagern wrote: >> Hi Igor, >> >> thanks for your status update. >> >> Igor Nekrestyanov wrote: >> >>> My understanding of current situation with Martin's fixes is the following: >>> - for 2 of Martin's fixes internal formal review procedure is in progress >>> (we do review all changes and save approved webrevs and this is >>> another reason why we ask for webrevs for contributions) >>> Unfortunately this procedure is not public and therefore it is hard >>> to track it status. However, it should not take long. >>> >> >> A short mail saying "Hi, I'm , I'll now start to review >> this and get back to you when I have questions or reached a verdict" >> would be a first step towards tracking that state, until more elaborate >> tracking tools and mechanisms become available. >> >> >>> - one of the suggested fixes actually introduces incompatibility in the >>> behavior >>> and such change has to be reviewed by CCC committee (this is how we >>> call it internally, >>> not sure what will be public name when it become public process) >>> [My understanding of incompatibility is: metadata written by "fixed" >>> jdk will not be parsed normally by older jdk] >>> >> >> Thanks, I'll look at this again, see if I have improvements or >> additional information to add regarding this. If so, I'll use the >> appropriate thread. >> >> >>> Andrew Brygin (who actually works on these 3 submissions) will provide >>> more accurate details about these 3 bugs later today. >>> >> >> Great! Looking forward to that. >> >> Martin >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.vGagern at gmx.net Mon Dec 8 13:46:07 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Mon, 08 Dec 2008 14:46:07 +0100 Subject: [OpenJDK 2D-Dev] Metadata: Unify text compression method attributes Message-ID: <493D251F.5090708@gmx.net> Hi! As it seems that my previous PNG metadata patches are going somewhere, and also that serious feature changes require a lot of time, I now want to discuss a thing I noticed when working on the PNG metadata. Consider a PNG file with compressed text chunks. How would they be expressed in Metadata? standard metadata: compression="zip" png metadata zTXt: compressionMethod="deflate" png metadata iTXt: compressionFlag="TRUE" compressionMethod="0" All the time the underlying compression method is the same. I suggest the following changes: 1. add "deflate" to the list of allowed values for the compression attribute in the standard metadata format. Rationale: to me, "zip" and "deflate" are different things. This corresponds to the difference between ZipOutputStream and DeflaterOutputStream in java.util.zip. I don't know whether there is in fact any image format actually using "zip", or if the meaning is "deflate" in every instance. If so, the "zip" value might be replaced. 2. change the combination of compressionFlag and compressionMethod for iTXt chunks to a single compression attribute with enumerated values, including the values "none" and "deflate". Rationale: Having to deal with integer constants defined in the PNG specification is cumbersome and contrary to implementation elsewhere in the metadata formats. Using "none" as one of the values gets rid of the separate compressionFlag and thus avoids dealing with strange cases where compressionFlag is "FALSE" and the compressionMethod attrribute is missing, unallowed, or whatever. As both these changes break compatibility, I guess they both should be included in a version bump of the metadata formats from 1.0 to 1.1. Large parts of the metadata handling code would be unaffected by this change, only a few places would require case distinctions. If you agree with my opinions, I would start working on an appropriate patch. If you have different suggestions, let me know. If there is something else that would require a bump of metadata versions, now would be a good time to collect this information. Greetings, Martin von Gagern -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From jennifer.godinez at sun.com Mon Dec 8 18:37:57 2008 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Mon, 08 Dec 2008 18:37:57 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6665212: PrinterJob class, method lookupStreamPrintServices(), "fos" in docs is unknown Message-ID: <20081208183818.17D4DD399@hg.openjdk.java.net> Changeset: b0c446712fae Author: jgodinez Date: 2008-12-08 10:23 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b0c446712fae 6665212: PrinterJob class, method lookupStreamPrintServices(), "fos" in docs is unknown Reviewed-by: tdv, prr ! src/share/classes/java/awt/print/PrinterJob.java From Phil.Race at Sun.COM Mon Dec 8 23:24:10 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Mon, 08 Dec 2008 15:24:10 -0800 Subject: [OpenJDK 2D-Dev] Still waiting for review In-Reply-To: <493D0D54.5040102@gmx.net> References: <493CF804.6000202@gmx.net> <1228733739.3712.6.camel@dijkstra.wildebeest.org> <493D0D54.5040102@gmx.net> Message-ID: <493DAC9A.10703@sun.com> We're going to institute some better tracking of these, at least in the 2D team, so that individual engineers beng tied up doesn't leave these forgotten on the floor (not that these were forgotten, just backlogged). The fixes look OK although there's a few tweaks we think are needed - to both your IIO fixes and Mark's pisces fixes. We are making those. But there are some things I need to make sure of from our checklist, eg - patch in an acceptable format (webrev preferred) - follows coding standards - has regression test, or explanation why this isn't possible (eg build fix, doc fix, perf fix ..) - contributor of the fix has signed the Sun Contributor Agreement. The regression test inclusion is a standard we apply internally too. Martin's fixes look to pass all of these tests, but for Mark's we'll need to either receive or attempt to create a regression test. In addition I recall from another thread (http://mail.openjdk.java.net/pipermail/build-dev/2008-November/001613.html) that we need to receive Mark's fix via Redhat to be covered under the SCA The SCA is a requirement that we need to check before integrating, I know this can sound like setting roadblocks, but as individual engineers we are not empowered to waive this requirement. Mark : can you please resubmit. Then we'll get them in ASAP. -phil. Martin von Gagern wrote: > Mark Wielaard wrote: > >> Martin, if you like we can use IcedTea http://icedtea.classpath.org/ as >> staging area for these fixes. That is what I do after testing. The above >> two fixes are already in IcedTea6 for a couple of months since I know >> other users are seeing the same bugs. That way things are at least >> picked up in a timely manner for the various GNU/Linux distros out >> there. http://icedtea.classpath.org/hg/icedtea6 >> > > Hi Mark! > > Looking at the IcedTea FAQs I read "It is not a fork of the OpenJDK, and > doesn't contain the OpenJDK source code". So I'm a bit surprised about > the suggestion. Looking at the repository, I see a collection of > patches, which seems to be the place you had in mind. > > While I like the idea of making my chnges available to distros even > before they have been officially accepted into OpenJDK, it feels a bit > like a misuse of the IcedTea project. A community-driven experimental > fork would be more suitable to stage such patches imho. > > As acceptance into OpenJDK still is my primary goal, and as Igor's mail > indicates light at the end of the tunnel in that direction, I'm inclined > to rather wait for the review than invest additional effort into pushing > those patches into yet another project. > > Still thanks for the suggestion, I'll keep it in mind and get back to > that if things don't work out here. > > Greetings, > Martin > > From dmitri.trembovetski at sun.com Tue Dec 9 01:12:27 2008 From: dmitri.trembovetski at sun.com (dmitri.trembovetski at sun.com) Date: Tue, 09 Dec 2008 01:12:27 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6772137: D3D: Dragging the scroll bar of a JScrollPane containing a JTree causes incorrect red Message-ID: <20081209011257.AD9FBD43D@hg.openjdk.java.net> Changeset: b163d898f83f Author: tdv Date: 2008-12-08 17:04 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b163d898f83f 6772137: D3D: Dragging the scroll bar of a JScrollPane containing a JTree causes incorrect red Reviewed-by: campbell ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h From roman.kennke at aicas.com Wed Dec 10 14:13:37 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Wed, 10 Dec 2008 15:13:37 +0100 Subject: [OpenJDK 2D-Dev] [PATCH] FontManager refactoring In-Reply-To: <491CCCDF.4040606@sun.com> References: <1224251121.6734.25.camel@moonlight> <491CCCDF.4040606@sun.com> Message-ID: <1228918417.7001.73.camel@moonlight> Hi Phil, I finally got around to fix up the font manager stuff. Some comments from me inline. > > this is the big FontManager refactoring patch I already mentioned a > > couple of times. It's primary purpose is to make the font implementation > > more portable (or: portable at all), allowing alternative/derived > > implementations to be plugged in. The general architecture breaks down > > as follows: > > Plugging in alternate architectures is somewhat interesting but the refactoring > priority I see is that the FontManager class which has grown too large and > needs to be "downsized" This is done, which is OK, Well, for me it's equally important to plug in something else. On the systems I work on I have no system fonts available, so I'd like them to be built in and loaded from the application JAR instead. Works quite nice until now, although it needs some more work in the fontmanager code, but this should come after this patch here is through. > and the most important > part of how this is done is to separate out the platform, and that's partly > handled but, not as much as I'd like. For example : SunFontManager.java : > getDefaultPlatformFont() seems like a perfect candidate for pushing > down into the platform code. > The FontConfigManager class should go with it into the X11 side of the code. I did this now. The fontmanager stuff is now in the solaris tree, and the getDefaultPlatformFont() abstract in SFM and implemented in both platform subclasses. > It would be nice if each of these new classes had its charter documented > at the top, in a class comment. Fixed. I only added some rather small comments, probably needs extension. The thing is that to me it's pretty clear what each of these classes should do, would be nice to have somebody else look at it and see what is missing. > I guess previously we had an X11/Win32GE instance for API reasons, but when the > font code was moved out to the FontManager subclasses it maybe wasn't > needed to make that also have an instance? TBH, I don't understand this question. Have instance of what? > Is DefaultFontManager really necessary?? Seems not to me. Removed. This was an artifact from me not wanting to have native stuff in SFM. Now the native stuff is simply moved to the platform implementations. > Also a number of changes appear unrelated, eg : > make/java/nio/Makefile > make/java/nio/spp.sh > src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java > src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java Also an artifact of me fixing broken stuff in other places. I removed this. > make/sun/font/mapfile-vers > The disappearance of these seems strange .. > 40 Java_sun_font_FontManager_getFont2D; > 41 Java_sun_font_FontManager_setFont2D; > 42 Java_sun_font_FontManager_isCreatedFont; > 43 Java_sun_font_FontManager_setCreatedFont; > .. ah, I see these are now using reflection In FontUtilities > Hmm. I don't think this change should be made > 1) As it stands it'll get a SecurityException > 2) I'm very dubious about changing the accessibility of these internal methods > Looks like a potential security hole. > 3) I'd want to such a change separately anyway to test its relative performance. As mentioned earlier, I think the best solution to this code is the SharedSecrets mechanism, which has the advantage to be compile-time-safe, doesn't need access checks, should be secure and should have best performance (no JNI call, no reflection call). > src/share/classes/java/awt/Component.java, and > src/windows/classes/sun/awt/windows/WToolkit.java > This was left in for a licensee, I'd be inclined to leave it alone > unless removing it has definite benefits. > 2770 // REMIND: PlatformFont flag should be obsolete soon... > 2771 if (sun.font.FontManager.usePlatformFontMetrics()) { > 2772 if (peer != null && > 2773 !(peer instanceof LightweightPeer)) { > 2774 return peer.getFontMetrics(font); > 2775 } > 2776 } > 2777 return sun I put it back in, including a comment to not remove it. > We don't need these and similar changes, since they aren't pre-defined constants > : > isSolaris->IS_SOLARIS, isLinux->IS_LINUX > > ie all caps is just for pre-defined constants, not ones determined at run time. Fixed. > Cmap.java > Please try to keep lines <=80 chars, eg line 411 here : > 410 if (FontUtilities.isLogging()) { > 411 FontUtilities.getLogger().warning("Cmap subtable overflows > buffer."); > 412 } > 413 } Hmm, How can I check all my code for this? > CompositeFont.java > 57 private SunFontManager fm = null; > > I don't see why every comp-font needs a ptr to this singleton. Removed. > PhysicalStrike.java > - 29 import java.awt.GraphicsEnvironment; > this isn't used Removed. > I'm not sure about the movement of addToPool() to TrueTypeFont.java > Theoretically its independent of the font format, and could apply > to any FileFont subclass. > also the file closer shut down hook isn't needed except for created > fonts from tmp files, so that shouldn't be started unless needed. I moved this code to a new class called FontChannelPool, and only start the hook when needed. > FontManager.java has a lot of "TODO" comments I added the missing comments. > Why is FontManagerForSGE needed? > ie why cannot SunFontManager be the class in which these are defined. I think I already replied to this. This is needed when an implementation wants to subclass SunGraphicsEnvironment but not reuse SunFontManager, just like I do. I have a fairly close GraphicsEnvironment, but a completely different FontManager here. > Win32FontManager : > 22 // FIXME: Windows build still needs to be abstracted from > 23 // SunGraphicEnvironment > 24 > What does that mean? Dunno. :-) I removed it. > 25 // please, don't reference sgEnv in any other code in this class > 26 // use getGraphicsEnvironment. > 27 @Deprecated > This doesn't seem an appropriate use of deprecated. > 28 private static SunGraphicsEnvironment sgEnv = null; Infact, this fields wasn't even used anymore, so I removed it. The updated webrev can be found here: http://kennke.org/~roman/fontmanager/webrev/ Have fun, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From martinrb at google.com Wed Dec 10 21:29:19 2008 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Dec 2008 13:29:19 -0800 Subject: [OpenJDK 2D-Dev] JNI crashes in FontManager code In-Reply-To: <48FDAB41.40200@sun.com> References: <1ccfd1c10810161723m54dfb7dar8a38bdde2aec196b@mail.gmail.com> <48F99950.8020903@sun.com> <1ccfd1c10810191416h18e5121ep8125cb2ec5fc27c4@mail.gmail.com> <48FDAB41.40200@sun.com> Message-ID: <1ccfd1c10812101329wb2b32c7i8127deba6febb976@mail.gmail.com> Ping. A crash found in testing by users seems pretty high priority. Martin On Tue, Oct 21, 2008 at 02:13, Igor Nekrestyanov wrote: > Thanks! > > I've filed bug 6761791 and plan to evaluate suggested fix in more > details/fix the bug soon. > > -igor > > Martin Buchholz wrote: >> >> Igor, I did some more digging, and I have a stack trace for you >> >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> V [libjvm.so+0x298366] >> C [libfontmanager.so+0x59e4] >> C [libfreetype.so.6+0x73c9] FT_Stream_Close+0x19 >> C [libfreetype.so.6+0xa065] FT_Stream_Free+0x25 >> C [libfreetype.so.6+0xa6e2] >> C [libfreetype.so.6+0xaf78] FT_Done_Face+0x78 >> C [libfontmanager.so+0x6964] >> Java_sun_font_FreetypeFontScaler_disposeNativeScaler+0x34 >> >> (sorry for the lack of debug info) >> >> (These are all running on Linux) >> >> Hope this helps. >> >> Martin >> > > From Igor.Nekrestyanov at Sun.COM Wed Dec 10 21:57:44 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Thu, 11 Dec 2008 00:57:44 +0300 Subject: [OpenJDK 2D-Dev] JNI crashes in FontManager code In-Reply-To: <1ccfd1c10812101329wb2b32c7i8127deba6febb976@mail.gmail.com> References: <1ccfd1c10810161723m54dfb7dar8a38bdde2aec196b@mail.gmail.com> <48F99950.8020903@sun.com> <1ccfd1c10810191416h18e5121ep8125cb2ec5fc27c4@mail.gmail.com> <48FDAB41.40200@sun.com> <1ccfd1c10812101329wb2b32c7i8127deba6febb976@mail.gmail.com> Message-ID: <49403B58.7020403@sun.com> Yes, we certainly will integrate fix for this problem soon. Forgot to submit updated fix for review before vacation. Will do this week. -igor Martin Buchholz wrote: > Ping. > > A crash found in testing by users seems pretty high priority. > > Martin > > On Tue, Oct 21, 2008 at 02:13, Igor Nekrestyanov > wrote: > >> Thanks! >> >> I've filed bug 6761791 and plan to evaluate suggested fix in more >> details/fix the bug soon. >> >> -igor >> >> Martin Buchholz wrote: >> >>> Igor, I did some more digging, and I have a stack trace for you >>> >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >>> code) >>> V [libjvm.so+0x298366] >>> C [libfontmanager.so+0x59e4] >>> C [libfreetype.so.6+0x73c9] FT_Stream_Close+0x19 >>> C [libfreetype.so.6+0xa065] FT_Stream_Free+0x25 >>> C [libfreetype.so.6+0xa6e2] >>> C [libfreetype.so.6+0xaf78] FT_Done_Face+0x78 >>> C [libfontmanager.so+0x6964] >>> Java_sun_font_FreetypeFontScaler_disposeNativeScaler+0x34 >>> >>> (sorry for the lack of debug info) >>> >>> (These are all running on Linux) >>> >>> Hope this helps. >>> >>> Martin >>> >>> >> From andrew.brygin at sun.com Fri Dec 12 14:51:48 2008 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Fri, 12 Dec 2008 14:51:48 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 5106550: PNG writer merge standard metadata fails for TextEntry sans #IMPLIED attributes Message-ID: <20081212145214.DFF48D6B2@hg.openjdk.java.net> Changeset: 9d14b0582e1a Author: bae Date: 2008-12-12 17:38 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9d14b0582e1a 5106550: PNG writer merge standard metadata fails for TextEntry sans #IMPLIED attributes Reviewed-by: igor, prr Contributed-by: Martin von Gagern ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java + test/javax/imageio/plugins/png/MergeStdCommentTest.java From Andrew.Brygin at Sun.COM Fri Dec 12 15:26:22 2008 From: Andrew.Brygin at Sun.COM (Andrew Brygin) Date: Fri, 12 Dec 2008 18:26:22 +0300 Subject: [OpenJDK 2D-Dev] 5106550: PNG writer merge standard metadata fails for TextEntry sans #IMPLIED attributes In-Reply-To: <491813D1.5010207@gmx.net> References: <491813D1.5010207@gmx.net> Message-ID: <4942829E.7080009@sun.com> Hello Martin, As you probably saw your fix for 5106550 was just pushed into 2d workspace (http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9d14b0582e1a) There is short status for other two your suggested fixes: - 5082756: finished engineering review, waiting for CCC decision. - 6541476: as we had commited fix for this bug id I'd submitted new bug report (6782079) for this problem. Fix is being reviewed now. Both these suggested fixes were tweaked during engineering review. I'll send you updated webrevs separately as they seems to be a bit too large to send everyone on this list : ) (about 1Mb). Thanks, Andrew Martin von Gagern wrote: > Bug ID: 5106550; State: 3-Accepted, bug; Priority: 4-Low > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5106550 > > The bug lies in the fact that for TextEntry nodes in standard metadata > format, PNGMetadata requires additional attributes besides the ones > marked #REQUIRED in the DTD. Namely missing encoding, language or > compression will result in an IIOInvalidTreeException: > >> Exception in thread "main" javax.imageio.metadata.IIOInvalidTreeException: Required attribute encoding not present! >> at com.sun.imageio.plugins.png.PNGMetadata.fatal(PNGMetadata.java:1085) >> at com.sun.imageio.plugins.png.PNGMetadata.getAttribute(PNGMetadata.java:1208) >> at com.sun.imageio.plugins.png.PNGMetadata.getAttribute(PNGMetadata.java:1217) >> at com.sun.imageio.plugins.png.PNGMetadata.mergeStandardTree(PNGMetadata.java:1921) >> at com.sun.imageio.plugins.png.PNGMetadata.mergeTree(PNGMetadata.java:1232) >> at MergeStdCommentTest.main(MergeStdCommentTest.java:37) >> > > The patch fixes this by > 1. not reading the "encoding" attribute at all, > as it isn't even used in the following code > 2. having the "language" attribute default to "", > as http://www.w3.org/TR/PNG/#11iTXt states that > "if the language tag is empty, the language is unspecified" > 3. having the "compression" attribute default to "none", > as this is the default given in the DTD > 4. ignore any node with missing or empty "keyword", > as the PNG standard requires a keyword of length at least 1 > according to http://www.w3.org/TR/PNG/#11tEXt > > I changed invocations from the previously used > private String getAttribute(Node node, String name) > which implied a required argument to the more flexible > private String getStringAttribute(Node node, > String name, > String defaultValue, > boolean required) > > Open question: > Do you agree in dropping nodes with missing keywords? > This follows the concept of not merging parts of the standard metadata > model which have no counterpart in a specific file format, but might > still lead to unexpected behaviour. > > I previously had this fix submitted to jdk7-dev, and mentioned in a > posting "Bug fixes for com.sun.imageio.plugins.png.PNGMetadata" here. > http://mail.openjdk.java.net/pipermail/jdk7-dev/2008-October/000272.html > http://mail.openjdk.java.net/pipermail/2d-dev/2008-November/000540.html > > In the meantime, I have had a look at the mq extension of mercurial. > Thus the attached patch is now a single patch straight out of my patch > queue. I submit it here, waiting for comments, discussion, sponsorship. > Once you consider it ready for inclusion, I can commit it localy and > post a patch exported by hg. > > Greetings, > Martin von Gagern > From Martin.vGagern at gmx.net Fri Dec 12 17:23:07 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Fri, 12 Dec 2008 18:23:07 +0100 Subject: [OpenJDK 2D-Dev] 5106550: PNG writer merge standard metadata fails for TextEntry sans #IMPLIED attributes In-Reply-To: <4942829E.7080009@sun.com> References: <491813D1.5010207@gmx.net> <4942829E.7080009@sun.com> Message-ID: <49429DFB.5040405@gmx.net> Andrew Brygin wrote: > As you probably saw your fix for 5106550 was just pushed into 2d > workspace > (http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9d14b0582e1a) Yes, I noticed, thanks. Comparing that changeset with my patch, I found that the patch now also ignores invalid keywords for the native PNG metadata format. I am a bit surprised by this, as I would expect the PNG metadata tree to be written to file entirely, without silently dropping parts. As sane PNG applications and images never should generate such invalid keywords in the first place, they won't be affected. When transcoding PNG files it might make sense to drop invalid keywords, in order to write valid files even after reading invalid ones. However, if an application tries to write invalid keywords, I'd rather see an exception than the text chunks being silently dropped. This is especially important in theoretical applications that allow the user the specification or arbitrary keywords and don't perform any validity checkings by themselves. On the whole, I can see reasons for those additional modifications, but I wouldn't have included them myself in quite this way. Thanks for reviewing and pushing this bugfix! > There is short status for other two your suggested fixes: I'll comment on #6782079 in the appropriate thread. Greetings, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From Martin.vGagern at gmx.net Fri Dec 12 17:23:20 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Fri, 12 Dec 2008 18:23:20 +0100 Subject: [OpenJDK 2D-Dev] 6782079: PNG: reading metadata may cause OOM on truncated images In-Reply-To: <491AD490.8060806@gmx.net> References: <491813DC.3030805@gmx.net> <491AD490.8060806@gmx.net> Message-ID: <49429E08.2090002@gmx.net> Hi Andrew, Looking at the patch from the webrev you sent me via private email, and comparing it to my previous bug6541476-corrections.patch, I have some comments. The addition of a maxLength parameter to readNullTerminatedString makes sense, as it avoids some problems on malformed input. It is my understanding, however, that all strings read via readNullTerminatedString should in a well formed PNG actually be null terminated. Therefore in my opinion reaching the limit should cause an exception to be thrown, not simply return the string read so far. There was a hunk in my patch changing the possible valies for compressionFlag of an iTXtEntry from 1/0 to TRUE/FALSE. YOu moved this change to your patch for 5082756. That's OK by me, but requires patches to be applied in the corret order. That's the reason I had that change bundled with my patch. Greetings, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From Igor.Nekrestyanov at Sun.COM Fri Dec 12 17:44:12 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Fri, 12 Dec 2008 20:44:12 +0300 Subject: [OpenJDK 2D-Dev] 6782079: PNG: reading metadata may cause OOM on truncated images In-Reply-To: <49429E08.2090002@gmx.net> References: <491813DC.3030805@gmx.net> <491AD490.8060806@gmx.net> <49429E08.2090002@gmx.net> Message-ID: <4942A2EC.7030001@sun.com> Hi Martin, > There was a hunk in my patch changing the possible valies for > compressionFlag of an iTXtEntry from 1/0 to TRUE/FALSE. YOu moved this > change to your patch for 5082756. That's OK by me, but requires patches > to be applied in the corret order. That's the reason I had that change > bundled with my patch. There is a reason behind this. Technically such change is change in the behavior and has to be reviewed by CCC. That's why it was suggested to rearrange code a bit to have single CCC review thread. -igor From linuxhippy at gmail.com Sun Dec 14 18:47:16 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sun, 14 Dec 2008 19:47:16 +0100 Subject: [OpenJDK 2D-Dev] Howto get RGB-values from a Glyph? Message-ID: <194f62550812141047r590854fat99ad2159c5f1e07f@mail.gmail.com> Hi, Is it possible to access the RGB-values of a Glyph in the case of lcd-antialiasing without native code? I only found GlyphList.getGrayBits(), but as far as I can see it only works with 1-byte-per-pixel values. Thank you in advance, Clemens From Andrew.Brygin at Sun.COM Mon Dec 15 13:42:06 2008 From: Andrew.Brygin at Sun.COM (Andrew Brygin) Date: Mon, 15 Dec 2008 16:42:06 +0300 Subject: [OpenJDK 2D-Dev] 6782079: PNG: reading metadata may cause OOM on truncated images In-Reply-To: <49429E08.2090002@gmx.net> References: <491813DC.3030805@gmx.net> <491AD490.8060806@gmx.net> <49429E08.2090002@gmx.net> Message-ID: <49465EAE.3070700@sun.com> Hi Martin, yes, I agree that the reaching the length limit likely signifies that png header is corrupt. Our usual policy is to try to be tolerant to errors in the images. There are too many not very well formed images around and being too strict we may reject too much. That's why I am inclined to avoid throwing exception. However, we probably should be smarter here and read at most min(maxLengthFromSpec, restOfChunkData) bytes. This way we will be able to recover after single corrupted chunk and start processing next chunk. Thanks, Andrew Martin von Gagern wrote: > Hi Andrew, > > Looking at the patch from the webrev you sent me via private email, and > comparing it to my previous bug6541476-corrections.patch, I have some > comments. > > The addition of a maxLength parameter to readNullTerminatedString makes > sense, as it avoids some problems on malformed input. It is my > understanding, however, that all strings read via > readNullTerminatedString should in a well formed PNG actually be null > terminated. Therefore in my opinion reaching the limit should cause an > exception to be thrown, not simply return the string read so far. > > There was a hunk in my patch changing the possible valies for > compressionFlag of an iTXtEntry from 1/0 to TRUE/FALSE. YOu moved this > change to your patch for 5082756. That's OK by me, but requires patches > to be applied in the corret order. That's the reason I had that change > bundled with my patch. > > Greetings, > Martin > > From Martin.vGagern at gmx.net Mon Dec 15 15:41:29 2008 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Mon, 15 Dec 2008 16:41:29 +0100 Subject: [OpenJDK 2D-Dev] 6782079: PNG: reading metadata may cause OOM on truncated images In-Reply-To: <49465EAE.3070700@sun.com> References: <491813DC.3030805@gmx.net> <491AD490.8060806@gmx.net> <49429E08.2090002@gmx.net> <49465EAE.3070700@sun.com> Message-ID: <49467AA9.4020406@gmx.net> Andrew Brygin wrote: > yes, I agree that the reaching the length limit likely signifies that > png header is corrupt. Our usual policy is to try to be tolerant to > errors in the images. There are too many not very well formed images > around and being too strict we may reject too much. That's why I am > inclined to avoid throwing exception. A malformed string will in almost all cases render the current chunk unusable. So as an alternative, you could throw a (newly introduced) MalformedChunkException and catch such an exception in the loop iterating over the chunks. This way, overlong strings and the resulting loss of synchronization could never lead to the allocation of unreasonable amounts of data or similar issue, as the broken chunk would be aborted cleanly. Just an idea. Greetings, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From Phil.Race at Sun.COM Mon Dec 15 18:15:10 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Mon, 15 Dec 2008 10:15:10 -0800 Subject: [OpenJDK 2D-Dev] Howto get RGB-values from a Glyph? In-Reply-To: <194f62550812141047r590854fat99ad2159c5f1e07f@mail.gmail.com> References: <194f62550812141047r590854fat99ad2159c5f1e07f@mail.gmail.com> Message-ID: <49469EAE.7080008@sun.com> Clemens Eisserer wrote: > Hi, > > Is it possible to access the RGB-values of a Glyph in the case of > lcd-antialiasing without native code? No, because there are no java-level loops that can handle the format. > I only found GlyphList.getGrayBits(), but as far as I can see it only > works with 1-byte-per-pixel values. Right. -phil. > > Thank you in advance, Clemens From Alexey.Ushakov at Sun.COM Tue Dec 16 00:43:50 2008 From: Alexey.Ushakov at Sun.COM (Alexey Ushakov) Date: Tue, 16 Dec 2008 03:43:50 +0300 Subject: [OpenJDK 2D-Dev] Still waiting for review In-Reply-To: <493D1CC6.4060001@sun.com> References: <493CF804.6000202@gmx.net> <1228733739.3712.6.camel@dijkstra.wildebeest.org> <493D03D4.3060606@sun.com> <493D0B46.1010401@gmx.net> <493D1954.60109@sun.com> <493D1CC6.4060001@sun.com> Message-ID: <4946F9C6.6060606@sun.com> Hi Mark, Here is an update on your fix concerning NPE in jfreechart&jxlayer applet. After some debugging I've created following minimized test case reproducing the problem that you faced with. As you can see the problem was caused by empty clip set to the graphics. So, I'm going to extend your fix with some additional checks for empty clip at the higher level. Also, following test can be used as regression one for the fix we're working on. (It's actually common practice in jdk development to create regression tests for the fixes) ------------------------------- public class Main extends JPanel { public static int WIDTH=200; public static int HEIGHT=200; public void paintComponent(Graphics g) { Graphics2D g2 = (Graphics2D)g; g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON); g2.setRenderingHint(RenderingHints.KEY_STROKE_CONTROL, RenderingHints.VALUE_STROKE_PURE); g2.setClip(new Rectangle2D.Double(0, 0,0,0)); g2.drawLine(0, 0, 100, 100); } public static void main(String[] args) { JFrame frame = new JFrame(); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.add(new Main()); frame.setPreferredSize(new Dimension(WIDTH,HEIGHT)); frame.pack(); frame.setVisible(true); } } -------------- Best Regards, Alexey Alexey Ushakov wrote: > Hi Mark, > > Please, read my comments about your patch. > > Sorry Martin, looks like this issue isn't yours. > > Best Regards, > Alexey > > Alexey Ushakov wrote: >> Hi Martin, >> >> I'm currently looking into >> http://www.jroller.com/dgilbert/entry/jfreechart_and_jxlayer >> >> issue and your patch. Unfortunately we're all working in parallel on >> many different project, so I'm unable to dedicate all my time for >> this task. Currently, I did verify that your fix does solve the >> problem but need more time to go through all the details of pisces AA >> engine to be sure that everything is OK. I'll let you know about any >> progress on this. >> >> Best Regards, >> Alexey >> >> Martin von Gagern wrote: >>> Hi Igor, >>> >>> thanks for your status update. >>> >>> Igor Nekrestyanov wrote: >>> >>>> My understanding of current situation with Martin's fixes is the following: >>>> - for 2 of Martin's fixes internal formal review procedure is in progress >>>> (we do review all changes and save approved webrevs and this is >>>> another reason why we ask for webrevs for contributions) >>>> Unfortunately this procedure is not public and therefore it is hard >>>> to track it status. However, it should not take long. >>>> >>> >>> A short mail saying "Hi, I'm , I'll now start to review >>> this and get back to you when I have questions or reached a verdict" >>> would be a first step towards tracking that state, until more elaborate >>> tracking tools and mechanisms become available. >>> >>> >>>> - one of the suggested fixes actually introduces incompatibility in the >>>> behavior >>>> and such change has to be reviewed by CCC committee (this is how we >>>> call it internally, >>>> not sure what will be public name when it become public process) >>>> [My understanding of incompatibility is: metadata written by "fixed" >>>> jdk will not be parsed normally by older jdk] >>>> >>> >>> Thanks, I'll look at this again, see if I have improvements or >>> additional information to add regarding this. If so, I'll use the >>> appropriate thread. >>> >>> >>>> Andrew Brygin (who actually works on these 3 submissions) will provide >>>> more accurate details about these 3 bugs later today. >>>> >>> >>> Great! Looking forward to that. >>> >>> Martin >>> >>> >> > From linuxhippy at gmail.com Tue Dec 16 23:30:23 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 17 Dec 2008 00:30:23 +0100 Subject: [OpenJDK 2D-Dev] Writing a GlyphCache with pure Java Message-ID: <194f62550812161530v30595b36vaf9e3b77139f1472@mail.gmail.com> Hello, 1.) I was trying to write a GlyphCache without native code, however I was struggling with some problems: - How to identify wether a glyph has already been cached or not (cellInfo->cacheID) - How to get notified that a glyph I cached is no longer valid, and its data structure has been freed (cellInfo->glyphInfo = NULL) Is it really not possible at all, or did I just miss something? If its not possible, any ideas how this could be implemented? I thought about one large Unsafe holding all the CacheCellInfo's, however that ends up with very dirty unsafe code and would mean a lot of memory-overhead - are there better ways to do this? 2.) Can GlyphList.fillBounds handle subPixPos? 3.) Would it make sence to replace the copy-loop in GlyphList.getGrayBits with Unsafe.copyMemory? I also found copy-loops + JNI-code in sun.java2d.pipe.RenderBuffer, using copyMemory could speed up small copies and remove some duplicated native code. Thanks, Clemens From igor.nekrestyanov at sun.com Wed Dec 17 19:10:33 2008 From: igor.nekrestyanov at sun.com (igor.nekrestyanov at sun.com) Date: Wed, 17 Dec 2008 19:10:33 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6761791: Crash in the FontManager code due to use of JNIEnv saved by another thread Message-ID: <20081217191057.A7A13DA04@hg.openjdk.java.net> Changeset: 11d333de082f Author: igor Date: 2008-12-17 22:00 +0300 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/11d333de082f 6761791: Crash in the FontManager code due to use of JNIEnv saved by another thread Reviewed-by: bae, prr ! src/share/native/sun/font/freetypeScaler.c From Igor.Nekrestyanov at Sun.COM Wed Dec 17 19:18:49 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Wed, 17 Dec 2008 22:18:49 +0300 Subject: [OpenJDK 2D-Dev] JNI crashes in FontManager code In-Reply-To: <1ccfd1c10812101329wb2b32c7i8127deba6febb976@mail.gmail.com> References: <1ccfd1c10810161723m54dfb7dar8a38bdde2aec196b@mail.gmail.com> <48F99950.8020903@sun.com> <1ccfd1c10810191416h18e5121ep8125cb2ec5fc27c4@mail.gmail.com> <48FDAB41.40200@sun.com> <1ccfd1c10812101329wb2b32c7i8127deba6febb976@mail.gmail.com> Message-ID: <49495099.2040904@sun.com> Fix for this problem was integrated. Note that it is different from suggested one (see http://hg.openjdk.java.net/jdk7/2d/jdk/rev/11d333de082f) as approach taken follows what we do for other rasterizer more closely. The idea is to ensure cached state is up to date. Then we do not need neither global JNIEnv nor global reference to font2d object. The caveat here is that i was not able to reproduce problem locally and therefore fix was not tested properly. Please let me know if it does not resolve the problem in your environment. -igor Martin Buchholz wrote: > Ping. > > A crash found in testing by users seems pretty high priority. > > Martin > > On Tue, Oct 21, 2008 at 02:13, Igor Nekrestyanov > wrote: > >> Thanks! >> >> I've filed bug 6761791 and plan to evaluate suggested fix in more >> details/fix the bug soon. >> >> -igor >> >> Martin Buchholz wrote: >> >>> Igor, I did some more digging, and I have a stack trace for you >>> >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >>> code) >>> V [libjvm.so+0x298366] >>> C [libfontmanager.so+0x59e4] >>> C [libfreetype.so.6+0x73c9] FT_Stream_Close+0x19 >>> C [libfreetype.so.6+0xa065] FT_Stream_Free+0x25 >>> C [libfreetype.so.6+0xa6e2] >>> C [libfreetype.so.6+0xaf78] FT_Done_Face+0x78 >>> C [libfontmanager.so+0x6964] >>> Java_sun_font_FreetypeFontScaler_disposeNativeScaler+0x34 >>> >>> (sorry for the lack of debug info) >>> >>> (These are all running on Linux) >>> >>> Hope this helps. >>> >>> Martin >>> >>> >> From martinrb at google.com Wed Dec 17 19:48:22 2008 From: martinrb at google.com (Martin Buchholz) Date: Wed, 17 Dec 2008 11:48:22 -0800 Subject: [OpenJDK 2D-Dev] JNI crashes in FontManager code In-Reply-To: <49495099.2040904@sun.com> References: <1ccfd1c10810161723m54dfb7dar8a38bdde2aec196b@mail.gmail.com> <48F99950.8020903@sun.com> <1ccfd1c10810191416h18e5121ep8125cb2ec5fc27c4@mail.gmail.com> <48FDAB41.40200@sun.com> <1ccfd1c10812101329wb2b32c7i8127deba6febb976@mail.gmail.com> <49495099.2040904@sun.com> Message-ID: <1ccfd1c10812171148lb0b20du2cd58bef652f6958@mail.gmail.com> Hi Igor, Thanks for working on fixing this. Your fix is indeed completely different from ours. Our fix was applied to openjdk6. We will soon be updating our openjdk6, and try to switch to your fix, after verifying that our crash remains fixed. It is a little troubling that we don't have a simple recipe to reproduce this crash. Perhaps one will be forthcoming from us. I recommend backporting this to jdk6, since it is a jdk crash fix. Martin On Wed, Dec 17, 2008 at 11:18, Igor Nekrestyanov wrote: > Fix for this problem was integrated. > > Note that it is different from suggested one (see > http://hg.openjdk.java.net/jdk7/2d/jdk/rev/11d333de082f) as approach taken > follows what we do for > other rasterizer more closely. > > The idea is to ensure cached state is up to date. Then we do not need > neither global JNIEnv nor global reference to font2d object. > > The caveat here is that i was not able to reproduce problem locally and > therefore fix was not tested properly. > Please let me know if it does not resolve the problem in your environment. > > -igor > > Martin Buchholz wrote: >> >> Ping. >> >> A crash found in testing by users seems pretty high priority. >> >> Martin >> >> On Tue, Oct 21, 2008 at 02:13, Igor Nekrestyanov >> wrote: >> >>> >>> Thanks! >>> >>> I've filed bug 6761791 and plan to evaluate suggested fix in more >>> details/fix the bug soon. >>> >>> -igor >>> >>> Martin Buchholz wrote: >>> >>>> >>>> Igor, I did some more digging, and I have a stack trace for you >>>> >>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>> C=native >>>> code) >>>> V [libjvm.so+0x298366] >>>> C [libfontmanager.so+0x59e4] >>>> C [libfreetype.so.6+0x73c9] FT_Stream_Close+0x19 >>>> C [libfreetype.so.6+0xa065] FT_Stream_Free+0x25 >>>> C [libfreetype.so.6+0xa6e2] >>>> C [libfreetype.so.6+0xaf78] FT_Done_Face+0x78 >>>> C [libfontmanager.so+0x6964] >>>> Java_sun_font_FreetypeFontScaler_disposeNativeScaler+0x34 >>>> >>>> (sorry for the lack of debug info) >>>> >>>> (These are all running on Linux) >>>> >>>> Hope this helps. >>>> >>>> Martin >>>> >>>> >>> >>> > > From phil.race at sun.com Thu Dec 18 19:32:27 2008 From: phil.race at sun.com (phil.race at sun.com) Date: Thu, 18 Dec 2008 19:32:27 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6708137: Remove obsolete fontconfig.98.properties from JDK 7 Message-ID: <20081218193241.1BEC6DA92@hg.openjdk.java.net> Changeset: feee56c07a8a Author: prr Date: 2008-12-18 11:25 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/feee56c07a8a 6708137: Remove obsolete fontconfig.98.properties from JDK 7 Reviewed-by: jgodinez, naoto ! make/sun/awt/Makefile ! src/windows/classes/sun/awt/windows/WFontConfiguration.java - src/windows/classes/sun/awt/windows/fontconfig.98.properties - src/windows/classes/sun/awt/windows/fontconfig.Me.properties From phil.race at sun.com Wed Dec 24 18:00:22 2008 From: phil.race at sun.com (phil.race at sun.com) Date: Wed, 24 Dec 2008 18:00:22 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 2 new changesets Message-ID: <20081224180052.E7A55DEA7@hg.openjdk.java.net> Changeset: f68864fe53d3 Author: prr Date: 2008-12-24 09:53 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f68864fe53d3 6728838: Native memory leak in StrikeCache.java Reviewed-by: bae, igor ! src/share/classes/sun/font/StrikeCache.java Changeset: 40ec164889bd Author: prr Date: 2008-12-24 09:57 -0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/40ec164889bd 6752638: java.awt.GraphicsEnvironment.preferLocaleFonts() throws NPE on Linux 6755034: Legal notice repair: jdk/src/solaris/classes/sun/font/FcFontConfiguration.java Reviewed-by: bae, igor ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/solaris/classes/sun/font/FcFontConfiguration.java + test/java/awt/GraphicsEnvironment/PreferLocaleFonts.java