------- Comment #7 from lucabon at interfree dot it 2010-02-11 15:38 ------- (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > > Use another Java-to-bytecode compiler and feed gcc with bytecode.
I'd like to use only free software... There is another free (GPL-compatible) java-to-bytecode compiler? > Btw, the symptoms you are seeing hint at not working garbage collection. > You might want to report this to your operating system vendor. Sorry, but I think the garbage collector is from gcc (libgcj), not from operating system. I try to substitute ecj1 with a shell script: #!/usr/bin/sh gij -cp /usr/share/java/ecj.jar org.eclipse.jdt.internal.compiler.batch.GCCMain "$@" And the simptom are the same, so I think the problem is inside gcc java interpreter. If I substitute "gij" with Sun "java", the compilation ends with "only" about 400MB memory used. Go deeply, gcj call ecj1 with the following arguments: ecj1 Anchor.java -w -fbootclasspath=../../../:/usr/share/java/libgcj-4.3.3.jar -fencoding=utf8 -fsource=1.5 -ftarget=1.5 -fzip-dependency /tmp/ccAgHLvl.zip -fzip-target /tmp/cccrxtPw.jar If I remove the last argument, class files are generated in the file system and ecj1/gij uses "only" about 130MB of memory. If I re-add the -fzip-target parameter with .class files into the file system, compilation is really fast. So, I think the problem is in gcc 64bit java interpreter when it stores the .class files in memory instead of file system. (In reply to comment #6) > Even if you fix this issue, I don't believe you will be able to compile > pdftk.cc with gcc 4.3 or later... > > http://gcc.gnu.org/ml/java/2008-03/msg00028.html > > due to the code incorrectly mixing c++ and java exceptions which are no longer > allowed under FSF gcc. pdftk will finally compile correctly (I have the executable), but it takes many hours to compile... I have only to apply a little patch to remove local java.security.MessageDigest. Luca -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41802
