This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Kill hack in java disabling unit-at-a-time
Jan Hubicka writes:
> > 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...
I don't understand. I thought unit-at-a-time kept all the bodies
until all the source had been parsed, and then generated code.
Andrew.