• GCJ_Optimization_Ideas

This is a collection of ideas related to optimizing the gcj compiler and libgcj runtime.

Rewrite use of StringBuffer and StringBuilder to gnu.gcj.runtime.StringBuffer

The libgcj specific class gnu.gcj.runtime.StringBuffer is an unsynchronized version of the java.lang.StringBuffer class. For code that uses java.lang.StringBuffer or java.lang.StringBuilder only from a single thread, it is safe to substitute gnu.gcj.runtime.StringBuffer

GCJ could analyze the code and if it determines that the substitution was safe it would make the substitution.

Eliminate calls to =''Jv''InitClass=

... for BC compilation

This email thread has some ideas http://gcc.gnu.org/ml/java/2006-05/msg00120.html

... for C++ ABI compilation

Currently this patch prevents us from eliminating class initializations from C++ ABI compilations. If we were to remove this, we could create some classes fully initialized, and have other classes avoid initializing these. For very important classes in the core we could rewrite them to explicitly initialize elsewhere, to avoid a penalty.

Inline most java.nio.Buffer* methods

Since all of the various java.nio.Buffer classes have private constructors, the compiler can know the layout and implementation details of all possible Buffer sub-classes. Given this knowledge it is possible to inline all methods of these classes. Using Buffers could then be as efficient as using arrays.

Break up monolithic libgcj.so

libgcj is huge compared to most libraries. It exports over 82000 symbols, which is beyond the system limit (64k) for exports from a shared library (DLL) on Windows platforms. The idea of breaking it up into a number of sublibraries has been mooted in the past, see for example

• http://gcc.gnu.org/ml/gcc/2005-04/threads.html#01450

• http://gcc.gnu.org/ml/java-patches/2005-q1/threads.html#00225

For more information on this idea, see Internal_dependencies_of_libgcj.