Re: optimizing for size

[Derek Rayside <drayside@mit.edu>]

I did some related work on this a few years ago in a paper called
"Compact Java Binaries for Embedded Systems" at CASCON'99:

	http://swen.uwaterloo.ca/~drayside/PAPERS/rayside_cascon99.pdf

Basically what we did was re-organize the constant pool (ie, symbol table)
to take advantage of the fact that fully qualified names have a tree
structure: eg, java/lang/Object.  We found that representing these as a
tree, rather than spelling out the name each time, saved 25% for
individual class files.  If we made a common constant pool for an entire
JAR file it would save about 50% of the total space.

We also experimented with some other encodings for the actual bytecodes,
but found that these didn't give us nearly as much of a win.

You probably don't have the luxury of using a different encoding, but most
of the work in the area indicates that the strings are where the bloat is.
One thing you could try is to use an application extractor, which you
could build with Soot, to extract the library classes you need from the
JDK (or GNU Classpath).  Then experiment with renaming the system classes
as well as your application classes.  You probably can't rename Object,
String, and URL, because these are very likely referenced by name from
inside the VM.  But you probably can rename most of the other classes in
the JDK/GNUclasspath.  Of course, the success of this approach will depend
on whether you measure size just in terms of your application classes or
in terms of the whole body of bytecode needed to execute the program.
Certainly your application classes will be smaller if they can refer to
system classes by names like a/b/c/ instead of java/lang/String.

Good luck,
Derek.


On Mon, 23 Jun 2003, David [iso-8859-1] Bélanger wrote:

> On Mon, Jun 23, 2003 at 05:15:15PM -0400, Navindra Umanee wrote:
> > Stephen Andrew Neuendorffer <neuendor@eecs.berkeley.edu> wrote:
> > > Obfuscating the strings in the bytecode will probably reduce code size more
> > > than anything else....
> > >
> > > There are several tools available for obfuscation, such as Jode
> > > (http://www.sourceforge.net),
> > > but as far as I know, Soot does not yet have this capability.
> >
> > Actually, David might have done something similar as part of his 621
> > project which was about optimizing bytecode for space.
> >
> > I'm not sure what the status of his code is, but I dropped him a note
> > in case he might want to chime in.
>
> I did some work on this for my 621 project.  I think the code was still
> quite unstable.  That code is currently unmaintained.
>
> I just put a copy of my final report here:
> http://www.sable.mcgill.ca/~dbelan2/621_final_report.ps
> I could package and make the code available in the next few days.
>
> The only component that may be stable enough for real-world application
> could be the renaming component.  Saving of 10% in space could
> potentially be obtained by renaming all fields/methods/classes.
>
>
> David
>
> ---
>
> David Bélanger
> Graduate Student
> School of Computer Science
> McGill University
> Office: MC226
>
> Web page:   http://www.cs.mcgill.ca/~dbelan2/
> Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt
>
>