[Bug libgcj/13806] New: linking requires excessive time/memory

[Bug libgcj/13806] New: linking requires excessive time/memory

[jsturm at gcc dot gnu dot org]

The final link is HUGE.  Libtool attempts to link all libgcj objects plus
several convenience libraries in one step.  (Though it may do incremental
linking due to command-length limits.)

On a not-really-obsolete Solaris 8 machine (440MHz US-IIi, 1GB) the final link
alone needs over 8 minutes and 320MB virtual memory to complete.

Consequently, it is difficult to build libgcj on smaller hardware, and many
developers may avoid it completely.

One possible fix is to break libgcj.so into several smaller libraries.

-- 
           Summary: linking requires excessive time/memory
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jsturm at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: sparc-sun-solaris2.8


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13806

[Bug libgcj/13806] linking requires excessive time/memory

[jsturm at gcc dot gnu dot org]

------- Additional Comments From jsturm at gcc dot gnu dot org  2004-01-22 02:22 -------
I forgot to mention: my test link used /usr/ccs/bin/ld (the native Solaris
linker, not GNU binutils).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13806

[Bug libgcj/13806] linking libgcj.so requires excessive time/memory

[jsturm at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|linking requires excessive  |linking libgcj.so requires
                   |time/memory                 |excessive time/memory


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13806

[Bug libgcj/13806] linking libgcj.so requires excessive time/memory

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-22 02:39 -------
Confirmed but the only thing we can do is split up the library as we have no control over ld if you 
are going to use Sun's ld.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-01-22 02:39:41
               date|                            |
            Version|unknown                     |3.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13806

[Bug libgcj/13806] linking libgcj.so requires excessive time/memory

[jsturm at gcc dot gnu dot org]

------- Additional Comments From jsturm at gcc dot gnu dot org  2004-01-22 13:58 -------
(In reply to comment #2)
> Confirmed but the only thing we can do is split up the library as we have no
control over ld if you 
> are going to use Sun's ld.

That's true.  But I have had similar results with GNU ld on some targets.  The
numbers I posted were intended as an example.  For that matter Gerald Pfeifer
reported a build failure on Solaris 9:

http://gcc.gnu.org/ml/java/2004-01/msg00055.html

I expect the library will be split someday.  For now I've opened this PR to
track the issue.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13806

[Bug libgcj/13806] linking libgcj.so requires excessive time/memory

[tromey at gcc dot gnu dot org]

------- Additional Comments From tromey at gcc dot gnu dot org  2004-01-22 17:37 -------
Yes, the current plan is to split the library into a core
part and then other lesser-used libraries.  so, for instance,
we would have lib-java-awt.so and lib-javax-swing.so for those
packages.  Ideally these separate libraries would be compiled
with -findirect-dispatch so that we wouldn't have library
ordering issues.

This is not static-linking-friendly so some thought would have to
be given to that.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13806

[Bug libgcj/13806] linking libgcj.so requires excessive time/memory

[daney at gcc dot gnu dot org]

------- Additional Comments From daney at gcc dot gnu dot org  2004-01-22 17:55 -------
I for one give a strong vote for breaking the library into separate parts.  We
are using libgcj in an embedded application where there is no need for AWT.  In
order to conserve space in ROM I have a custom build that strips all AWT classes
out of libgcj.

Having this done by the default build would make my life much easier.

A second problem that I am having that this would solve is the MIPS multi-got
problem.  Because of command line limitations on the build platfrom (x86/linux)
a full libgcj build has to be done with incremental linking.  Because of the way
MIPS PIC code is generated this forces us to use a large got (slower code)
instead of multi-got (faster code).  Any thing that moves us away from
incremental linking of libgcj is a win for runtime speed (as well as building
faster)

Can we target 3.4.1 instead of 3.5.0?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13806

[Bug libgcj/13806] linking libgcj.so requires excessive time/memory

[drow at mvista dot com]

------- Additional Comments From drow at mvista dot com  2004-01-26 15:06 -------
Subject: Re:  linking libgcj.so requires excessive time/memory

On Thu, Jan 22, 2004 at 05:55:02PM -0000, daney at gcc dot gnu dot org wrote:
> A second problem that I am having that this would solve is the MIPS multi-got
> problem.  Because of command line limitations on the build platfrom (x86/linux)
> a full libgcj build has to be done with incremental linking.  Because of the way
> MIPS PIC code is generated this forces us to use a large got (slower code)
> instead of multi-got (faster code).  Any thing that moves us away from
> incremental linking of libgcj is a win for runtime speed (as well as building
> faster)

[Side note]

Use binutils from CVS and this should be resolved in a more efficient
fashion than -xgot.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13806

[Bug libgcj/13806] linking libgcj.so requires excessive time/memory

[phython at gcc dot gnu dot org]

------- Additional Comments From phython at gcc dot gnu dot org  2004-11-26 13:52 -------
 This problem got worse after the BC branch merged in.  I can't link libgcj on
powerpc-linux anymore because the process gets killed every time.  I only have
256MB of ram.  I suspect I'll have the same trouble on sparc-linux and
hppa-linux as those boxes also only have 256MB or ram.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13806

[Bug libgcj/13806] linking libgcj.so requires excessive time/memory

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-26 23:58 -------
Is the situation better after the patch create one .o file per directory?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13806