*** MOVED ***

NOTE: I have merged the contents of this blog with my web-site. I will not be updating this blog any more.



I started tinkering with Tom's
project this weekend. On a cursory perusal, it definitely seems
more accessible to ordinary mortals than the current GCJ front end. It
is written in C++, a language that I am not too comfortable with, but
that should not be an insurmountable problem.

I built and ran GCJX against the current GCC mainline. I normally do
not actually install a newly built mainline GCC snapshot after the GCC
build process is complete, so using this compiler is a bit
different than normal - I used the following script to build GCJX using
such a GCC:


# Build GCJX


BLT_CXX="$GCC_BLD_DIR/gcc/g++ -B$GCC_BLD_DIR/gcc/ \
-I$GCC_BLD_DIR/$GCC_BLD_TGT/libstdc++-v3/include \
-I$GCC_BLD_DIR/$GCC_BLD_TGT/libstdc++-v3/include/$GCC_BLD_TGT \
-I$GCC_SRC_DIR/libstdc++-v3/libsupc++ \

make CXX="$BLT_CXX" typedefs.hh.gch

make CXX="$BLT_CXX" want_pch=yes

Compiling C++ programs that use STL with GCC can be quite slow, so I
am glad that newer GCC versions have pre-compiled header (PCH) support.
The script above uses PCH to build GCJX - on my little machine, the total
build time is reduced from 12m 2s to 6m 32s and an additional 11s to
build the PCH itself. That's quite an improvement!

Since GCJX does not come with its own class libraries, I used GNU
Classpath 0.10 sources appropriately updated
(create "gnu/classpath/Configuration.java" and copy over classes
under "vm/reference/" into the top folder) for use with GCJX.
After this, I could compile simple programs as:

lextest /path/to/classpath-0.10 . -- HelloWorld.java

This parses the given file and all files from the Java runtime
(quite a lot) needed for a complete closure and writes out class
files (and CNI header files) to "/tmp/gcjx-out" (which I had
to create beforehand). Note that I had to update LD_LIBRARY_PATH
to point to the folder containing the libstdc++.so file from the GCC
build folder as "lextest" depends on this library.

Compiling so many of the Java runtime classes over and over again every
time I want to compile a source file is a little wasteful, not to
mention quite slow, so I started giving the path to the libgcj build
folder from the GCC build folder and this speeded things up considerably.

My next task was to check GCJX against the Jacks testsuite. I had
to create an appropriate Jacks "gcjx_setup" file. Mine looks
like this:

set JAVAC /extra/src/gcjx/lextest
set JAVA /extra/src/gcc/build/i686-pc-linux-gnu/libjava/gij
set JAVA_FLAGS "-mx=64m"
set JAVAC_FLAGS {/extra/src/gcc/build/i686-pc-linux-gnu/libjava . -- -jacks}
set JAVAC_DEPRECATION_FLAG "-deprecated"
set tcltest::testConstraints(assert) 1

"-jacks" is a temporary flag that causes GCJX to suppress most
of its pedantic warnings and causes it to write out classes to the current
folder (instead of "/tmp/gcjx-out").

I got 4302 PASS-es, 541 FAILs and 76 UNTESTED out of a total of 4919 Jacks
testcases. This is not as good as what Tom reports, so I have to see what
has gone wrong - but in any case, it is much better than what the
current GCJ front end gives.

Great work Tom!

I want to see if I can add JAR/ZIP reading support to GCJX. This looks
doable and Tom already has most of the framework ready.

(Originally posted on Advogato.)

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.