Very slow compiler?

Alexandre Petit-Bianco apbianco@cygnus.com
Mon Sep 25 16:13:00 GMT 2000


Jeff Sturm writes:

> (That's not actually quite true.  Compiling to bytecode in
> topological order, i.e. starting with java.lang.Object, should be
> more efficient.  I haven't tried it.)

Well, it looks like the build system is setup so that when building
libgcj, only source files will be loaded.

Now, this is just something I witnessed, I haven't yet looked whether
we could do otherwise. We might have done things differently in the
past, though I mainly recall that gcj has sometimes troubles dealing
with mixed environments (something I plan on working on.)

> Are you sure all of these classes are not referenced directly or
> indirectly from ObjectStreamConstants?  FWIW, I tried your example
> and found 176 classes and interfaces loaded... the same with "javac
> -verbose" yielded 163.

This seems about right. Gcj won't load a class unless it has to or
unless it's seriously confused. 150+ sounds to be right for the core
libraries. Compiling a random awt file, for examples, triggers the
resolution of 300+ types.

I recently experimented with something else. I took a currently "slow"
gcj and used it to build an old version of libgcj. I built things in a
timely manner (less than a hour for a full build.) The new libgcj has
600+ files, the old one had only 300.

As a quick and temporary relief, I yesterday timed a build to 4 hours
if I totally disable Tom's iconv patch (Tom already has a faster iconv
patch, but I still have to test it.) Here's a Q&D patch:

./A

Index: jcf-parse.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/jcf-parse.c,v
retrieving revision 1.56
diff -u -p -r1.56 jcf-parse.c
@@ -770,6 +770,7 @@ parse_source_file (file, finput)
   /* There's no point in trying to find the current encoding unless we
      are going to do something intelligent with it -- hence the test
      for iconv.  */
+#undef HAVE_ICONV
 #ifdef HAVE_ICONV
 #ifdef HAVE_NL_LANGINFO
   setlocale (LC_CTYPE, "");
Index: jv-scan.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/jv-scan.c,v
retrieving revision 1.19
diff -u -p -r1.19 jv-scan.c
--- jv-scan.c   2000/09/13 17:09:36     1.19
+++ jv-scan.c   2000/09/25 23:05:41
@@ -191,6 +191,7 @@ DEFUN (main, (argc, argv),
            /* There's no point in trying to find the current encoding
               unless we are going to do something intelligent with it
               -- hence the test for iconv.  */
+#undef HAVE_ICONV
 #ifdef HAVE_ICONV
 #ifdef HAVE_NL_LANGINFO
            setlocale (LC_CTYPE, "");
Index: lex.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/lex.c,v
retrieving revision 1.42
diff -u -p -r1.42 lex.c
--- lex.c       2000/09/12 22:23:59     1.42
+++ lex.c       2000/09/25 23:05:44
@@ -210,6 +210,7 @@ java_new_lexer (finput, encoding)
   lex->bs_count = 0;
   lex->unget_value = 0;
 
+#undef HAVE_ICONV
 #ifdef HAVE_ICONV
   lex->handle = iconv_open ("UCS-2", encoding);
   if (lex->handle == (iconv_t) -1)



More information about the Java mailing list