This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: Enabling unit-at-a-time by default for Java


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.


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