May I respectfully point out that the gcc make process already has hard-coded hackery to work around the limitations of certain machines, oses, non-GNU makes, linkers, and assembers, etc? (The thing that comes to mind is the 42 item limit for make rules on AIX: see libstdc++-v3/include/Makefile.am. There are no doubt many others.)
Adding hacks to the java Makefiles to make parse.o compilable across a large variety of machines/os's seems necessary and essential. If not, the java build and testing base will only go down over time. This seems the opposite of what you want, especially after the big merge to ecj that was just finished.
Either this part of libjava can be made optional, or the rule for this object file can be made more complex, or the file can be compiled without optimizations, whatever. There seem to be a variety of approaches that would work.
I can understand the interest in wanting to delve deeper into the actual causes of the memory explosion with compiling java/html/parse.o, and the reluctance to add build hacks, but I am somewhat concerned with the response of the java maintainers (and others) that it's OK to require >512MB to bootstrap gcc with java, or that make times "WORKSFORME."
best, benjamin
