This is the mail archive of the java@gcc.gnu.org mailing list for the Java 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: libgcj_bc.so not embedded


Here's a summary of other conversation:

> > > Excessive code size growth could also be problem for some programs.
> > >
 > > 1) A solution is using the -shared option to generate ".so" library.
 >
 > That does not solve things in environments like embedded
 > environments where there are no shared libraries.

Use -Os and "strip --strip-all". And remove code if you don't like it.

 > > 2) Another future solution is pack the big ".so" library with UPX
 > > (Ultimate Packer for eXecutables) or extend the ELF format to
 > > permit pack the sections with GZ, BZ2 or LZMA.
 >
 > We are worried about code space in memory, not space on disk!

 Or extend the ELF format to permit pack non-solidly or solidly (=>
 slower stream) many subsections with GZ, BZ2, UPX or
 LZMA (<=1MiB to uncompress e.g.) variants to be refined all in one
 for better space ( only options -9, -best, ultra, ..).

 Their buffers are very small to permit to raise an exception.
 Like squashfs for embedded systems instead of cramfs.

This same idea is applicable to pack the gigantic /usr/lib/libgcj.so that its current non-packed size on disk is >=9 MiB, sometimes >=50 MiB.

Remember, Java is generated to C++ with gcj and compiled with g++.


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