Re: Kill hack in java disabling unit-at-a-time

[Jan Hubicka <jh at suse dot cz>]

> Jan Hubicka writes:
>  > > > Jan Hubicka writes:
>  > > > 
>  > > >  > apparently this hack went in with tree-ssa merge causing unit-at-a-time
>  > > >  > to be disabled by default since 4.0.0.  Fortunately re-enabling it don't
>  > > >  > seem to cause any regressions, however I will wait a day before
>  > > >  > commiting this so people might comment if this don't seem appropriate
>  > > >  > for stage3.
>  > > >  > 
>  > > >  > Bootstrapped/regtested i686-pc-gnu-linux, will commit it as obvious if
>  > > >  > no-one objects :)
>  > > > 
>  > > > It's far from obvious.  There were severe problems with unit-at-a-time
>  > > > and gcj, and this shouldn't go in without extensive testing.  A simple
>  > > > 'make check' and bootstrap isn't enough.  We'll need time to test this.
>  > > 
>  > > How do you propose to test it?  If we don't want unit-at-a-time to be
>  > > enabled for 4.1, can we just move it into option handling instead of
>  > > such a hidden hack?
>  > 
>  > Also can you tell me more about the severe problems?
> 
> Two things: firstly te compile ICEd in various random ways that I
> didn't have time to investigate.  Secondly, there was a tremendous
> growth in memory consumption, caused AFAICS by retaining method
> bodies.

Can I have testcase for at lest one of them?  Since Java pass all the
bodies at once to backend, the memory should not grow after all...

Honza
> 
> Andrew.
>