This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]