This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
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 <audriusa@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-----