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