Re: [cp-patches] Split gnu/javax/swing/text/html/parser/HTML_401F.java
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This change is ok. It should have no any impact on the algorithm. Audrius Andrew Haley wrote: On 07/28/2009 12:55 AM, Andrew John Hughes wrote: 2009/7/14 Audrius Meskauskas audri...@bluewin.ch: On Sun, Jul 12, 2009 at 10:27:07PM +0200, Gerald Pfeifer wrote: On Wed, 1 Jul 2009, Andrew Haley wrote: I haven't studied how exactly is --enable-java-maintainer-mode compiling the classes; if I just gcj -C HTML_401F.java on Fedora 11 (GCC 4.4.0, ecj 3.4.2), the compile time with patched VTA is only 4:53 with 1.5GB top memory usage, if I patch HTML_401F.java with the following patch, it compiles within 0:55 and maxes at 250MB. That's quite a nice improvement. HTML_401F.java has been causing troubles for many years, and splitting it really helps, for example building on (virtual) machines with not so much main memory or in limited settings where there is a process limit for 512MB. It's not an ABI change. This patch is OK iff accompanied by a comment in the code that explains the problem. I believe the patch has not made it into GCC Subversion yet. Are the two of you still planning to apply it? See http://gcc.gnu.org/viewcvs?root=gccview=revrev=149148 Jakub Masters, where is the beginning of this discussion and where is the proposed patch? I have received four messages about HTML_401F that look completely in the middle of the context. While it is great when somebody continues your work, I think it would make no harm for me to look into the patch on the class I once wrote. Audrius Meskauskas Audrius, the patch is visible from the link posted by Jakub: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149148 It simply splits the method which defines the entities into five separate methods to reduce load on the compiler. Is this generally useful? If so, it should go into GNU Classpath rather than just the downstream copy in GCJ. I think it should go into Classpath anyway: it doesn't hurt anything and it reduces divergence with gcj. Andrew. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp2CIIACgkQYtLS/5wKz7AuDQCgi667yXx++8u7GREOBFli3sWm 9f0AnAgLktVYkhVz2PPFQ/u/mr5llrHl =8iy1 -END PGP SIGNATURE-
Re: [cp-patches] Split gnu/javax/swing/text/html/parser/HTML_401F.java
On 07/28/2009 12:55 AM, Andrew John Hughes wrote: 2009/7/14 Audrius Meskauskas audri...@bluewin.ch: On Sun, Jul 12, 2009 at 10:27:07PM +0200, Gerald Pfeifer wrote: On Wed, 1 Jul 2009, Andrew Haley wrote: I haven't studied how exactly is --enable-java-maintainer-mode compiling the classes; if I just gcj -C HTML_401F.java on Fedora 11 (GCC 4.4.0, ecj 3.4.2), the compile time with patched VTA is only 4:53 with 1.5GB top memory usage, if I patch HTML_401F.java with the following patch, it compiles within 0:55 and maxes at 250MB. That's quite a nice improvement. HTML_401F.java has been causing troubles for many years, and splitting it really helps, for example building on (virtual) machines with not so much main memory or in limited settings where there is a process limit for 512MB. It's not an ABI change. This patch is OK iff accompanied by a comment in the code that explains the problem. I believe the patch has not made it into GCC Subversion yet. Are the two of you still planning to apply it? See http://gcc.gnu.org/viewcvs?root=gccview=revrev=149148 Jakub Masters, where is the beginning of this discussion and where is the proposed patch? I have received four messages about HTML_401F that look completely in the middle of the context. While it is great when somebody continues your work, I think it would make no harm for me to look into the patch on the class I once wrote. Audrius Meskauskas Audrius, the patch is visible from the link posted by Jakub: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149148 It simply splits the method which defines the entities into five separate methods to reduce load on the compiler. Is this generally useful? If so, it should go into GNU Classpath rather than just the downstream copy in GCJ. I think it should go into Classpath anyway: it doesn't hurt anything and it reduces divergence with gcj. Andrew.
Re: [cp-patches] Split gnu/javax/swing/text/html/parser/HTML_401F.java
2009/7/14 Audrius Meskauskas audri...@bluewin.ch: On Sun, Jul 12, 2009 at 10:27:07PM +0200, Gerald Pfeifer wrote: On Wed, 1 Jul 2009, Andrew Haley wrote: I haven't studied how exactly is --enable-java-maintainer-mode compiling the classes; if I just gcj -C HTML_401F.java on Fedora 11 (GCC 4.4.0, ecj 3.4.2), the compile time with patched VTA is only 4:53 with 1.5GB top memory usage, if I patch HTML_401F.java with the following patch, it compiles within 0:55 and maxes at 250MB. That's quite a nice improvement. HTML_401F.java has been causing troubles for many years, and splitting it really helps, for example building on (virtual) machines with not so much main memory or in limited settings where there is a process limit for 512MB. It's not an ABI change. This patch is OK iff accompanied by a comment in the code that explains the problem. I believe the patch has not made it into GCC Subversion yet. Are the two of you still planning to apply it? See http://gcc.gnu.org/viewcvs?root=gccview=revrev=149148 Jakub Masters, where is the beginning of this discussion and where is the proposed patch? I have received four messages about HTML_401F that look completely in the middle of the context. While it is great when somebody continues your work, I think it would make no harm for me to look into the patch on the class I once wrote. Audrius Meskauskas Audrius, the patch is visible from the link posted by Jakub: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149148 It simply splits the method which defines the entities into five separate methods to reduce load on the compiler. Is this generally useful? If so, it should go into GNU Classpath rather than just the downstream copy in GCJ. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] Split gnu/javax/swing/text/html/parser/HTML_401F.java
On Sun, Jul 12, 2009 at 10:27:07PM +0200, Gerald Pfeifer wrote: On Wed, 1 Jul 2009, Andrew Haley wrote: I haven't studied how exactly is --enable-java-maintainer-mode compiling the classes; if I just gcj -C HTML_401F.java on Fedora 11 (GCC 4.4.0, ecj 3.4.2), the compile time with patched VTA is only 4:53 with 1.5GB top memory usage, if I patch HTML_401F.java with the following patch, it compiles within 0:55 and maxes at 250MB. That's quite a nice improvement. HTML_401F.java has been causing troubles for many years, and splitting it really helps, for example building on (virtual) machines with not so much main memory or in limited settings where there is a process limit for 512MB. It's not an ABI change. This patch is OK iff accompanied by a comment in the code that explains the problem. I believe the patch has not made it into GCC Subversion yet. Are the two of you still planning to apply it? See http://gcc.gnu.org/viewcvs?root=gccview=revrev=149148 Jakub Masters, where is the beginning of this discussion and where is the proposed patch? I have received four messages about HTML_401F that look completely in the middle of the context. While it is great when somebody continues your work, I think it would make no harm for me to look into the patch on the class I once wrote. Audrius Meskauskas
Re: [cp-patches] Split gnu/javax/swing/text/html/parser/HTML_401F.java
Gerald Pfeifer wrote: On Wed, 1 Jul 2009, Andrew Haley wrote: I haven't studied how exactly is --enable-java-maintainer-mode compiling the classes; if I just gcj -C HTML_401F.java on Fedora 11 (GCC 4.4.0, ecj 3.4.2), the compile time with patched VTA is only 4:53 with 1.5GB top memory usage, if I patch HTML_401F.java with the following patch, it compiles within 0:55 and maxes at 250MB. That's quite a nice improvement. HTML_401F.java has been causing troubles for many years, and splitting it really helps, for example building on (virtual) machines with not so much main memory or in limited settings where there is a process limit for 512MB. It's not an ABI change. This patch is OK iff accompanied by a comment in the code that explains the problem. I believe the patch has not made it into GCC Subversion yet. I believe it has. Andrew.
Re: [cp-patches] Split gnu/javax/swing/text/html/parser/HTML_401F.java
On Wed, 1 Jul 2009, Andrew Haley wrote: I haven't studied how exactly is --enable-java-maintainer-mode compiling the classes; if I just gcj -C HTML_401F.java on Fedora 11 (GCC 4.4.0, ecj 3.4.2), the compile time with patched VTA is only 4:53 with 1.5GB top memory usage, if I patch HTML_401F.java with the following patch, it compiles within 0:55 and maxes at 250MB. That's quite a nice improvement. HTML_401F.java has been causing troubles for many years, and splitting it really helps, for example building on (virtual) machines with not so much main memory or in limited settings where there is a process limit for 512MB. It's not an ABI change. This patch is OK iff accompanied by a comment in the code that explains the problem. I believe the patch has not made it into GCC Subversion yet. Are the two of you still planning to apply it? Gerald
Re: [cp-patches] Split gnu/javax/swing/text/html/parser/HTML_401F.java
On Sun, Jul 12, 2009 at 10:27:07PM +0200, Gerald Pfeifer wrote: On Wed, 1 Jul 2009, Andrew Haley wrote: I haven't studied how exactly is --enable-java-maintainer-mode compiling the classes; if I just gcj -C HTML_401F.java on Fedora 11 (GCC 4.4.0, ecj 3.4.2), the compile time with patched VTA is only 4:53 with 1.5GB top memory usage, if I patch HTML_401F.java with the following patch, it compiles within 0:55 and maxes at 250MB. That's quite a nice improvement. HTML_401F.java has been causing troubles for many years, and splitting it really helps, for example building on (virtual) machines with not so much main memory or in limited settings where there is a process limit for 512MB. It's not an ABI change. This patch is OK iff accompanied by a comment in the code that explains the problem. I believe the patch has not made it into GCC Subversion yet. Are the two of you still planning to apply it? See http://gcc.gnu.org/viewcvs?root=gccview=revrev=149148 Jakub
