-----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=gcc&view=rev&rev=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=gcc&view=rev&rev=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-----