This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Enabling unit-at-a-time by default for Java
- From: Andrew Haley <aph at redhat dot com>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: gcc-patches at gcc dot gnu dot org, per at bothner dot com, java at gcc dot gnu dot org
- Date: Tue, 15 Jul 2008 11:47:02 +0100
- Subject: Re: Enabling unit-at-a-time by default for Java
- References: <20080714211805.GL28585@kam.mff.cuni.cz>
Jan Hubicka wrote:
> Hi,
> as discussed earlier, I would like to enable unit-at-a-time by default
> for Java. This will allow to drop non-unit-at-a-time for gcc 4.5 and
> also avoid hitting latent bugs since Java is now only user of
> non-unit-at-a-time.
>
> I've fixed some related problems related to memory usage and compilation
> time, so libjava now builds resonably (fater than before). Two
> remaining issues I know of are:
>
> 1) Testcase jonas.jar now requires about 9GB of ram instead of 3GB of
> ram to compile. I've looked into it and it is all actual gimple memory
> usage. About 4GB for gimple representation of program and other 5GB
> for other datastructures.
>
> SSA operand caches are particularly
> ineffective for small functions, so some improvement can be done here.
> Tuples ought to help here, but last time I tried the tuples branch
> actually needed more RAM than mainline. They should trim out something
> out of the 4GB of Gimple usage.
>
> 2) I get libjava.lang/StackTrace2 failure at -O3. This testcase tests
> that unwind info reports proper name of function doing non-call EH
> (at least in my understnading of Java). Inlining of the throwing
> function naturally changes its name in unwind info, yet I don't see how
> inliner can work out that inlining is not supposed to happen.
>
> I guess StackFrame feature is not really compatible with inlining, but
> I might be missing something. It is definitly latent problem and
> probably minor one.
>
> OK for mainline?
OK, thanks. I'll fix the StackTrace2 problem.
Andrew.