Ian D. Stewart wrote:
>
> Jochen Hoenicke wrote:
> >
> > Hello Ian,
> >
> > [Sorry, for sending a blank mail, but emacs' key sequence for sending
> > mail (C-c C-c) is really bad chosen...]
> >
> > On May 10, Ian D. Stewart wrote:
> > > Rather, it is one of system resources. Using the "en mass" method, the
> > > compiler attempts to compile all the classes of the classpath library at
> > > once, and doesn't stop until it is done, or until it consumes enough
> > > memory to degrade the systems performance enough to require a cold boot
> > > (normally the latter)
> > >
> > > On a relatively modern system, this is probably not much of an issue.
> > > However, as I mentioned in passing in my previous e-mail, I am running
> > > an older system. Specifically:
> > >
> > > Processor: 75MHz Pentium
> > > Memory: 16 MB Physical; 64 MB swap
> > > Hard Drive: 1.2 GB WD Caviar w/ ~150 MB free
> >
> > Do you specify the correct heap size to javac (-J-mx12M)? You should
> > make the heap a bit smaller than physical memory size, or the garbage
> > collection won't run early enough and performance will hurt. 12 MB is
> > a guess, you may try using a bit more. My experience is that if java
> > starts swapping you can kill it immediately, since it gets damn slow.
> > Also if swap gets exhausted linux starts killing random apps, but that
> > is another problem often discussed on linux-kernel.
> >
> > If you get an OutOfMemoryError, you are right, you can't compile
> > everything at once. But have you tried jikes? I don't know its
> > memory usage, but its speed is really great.
>
> Hi Jochen,
>
> Thanx for the response. No, I hadn't tried -Xmx. I'll give it a shout
> and see how it goes. Somebody else had suggested building individual
> packages at a time. I'll try both and report back how it goes.
Well, after some experimentation, I believe I've come across a workable
solution. By shutting down all services, including X11, using the
Blackdown interpreter (/usr/local/jdk117_v3/bin/java on my system) in
place of Japhar (this, in and of itself resulted in an order of
magnitude improvement in speed and got rid of the lock-up problem) and
setting max heap size to 48 MB (I tried both 12 MB and not specifying
and max, which then defaults to 32 MB. In both cases the compiler ran
quite smoothly until it reached the heap size limit, then promptly died
with 'java.lang.OutOfMemoryError') I am able to compile most of the Java
source.
Several classes did not build due to dependencies on gnu.java packages
which hadn't been built yet. Also, I needed to apply Mark Wielaard's
patch for java/lang/String.java, et al. No big deel. I applied the
patch and rebuilt classpath.
This is when I came across a rather annoying (at least to my mind)
"feature" of the classpath build process. Instead of only building
those classes that had changed, or had not yet been compiled, the entire
classpath library was built from scratch. I believe this is due to the
fact that the 'compile-classes' target explicitly specifies which files
to build.
In an effort to be part of the solution, I next went about modifying the
Makefile for lib to add an implicit rule for .class files. Thus, by
changing glibj's dependencies to 'classes $(HEADERS_DEPEND) $(JAVA_SRCS)
$(CLASSES)', this would force a compile of only those files needing
compilation, while leaving the 'compile-classes' target intact for those
wishing to building "en mass".
Unfortunately, when I went to rebuild using the new rules, I received
the following error: "No rule to make target
'java/awt/EventQueue.class', needed by 'glibj.zip'. Stop"
Here is the implicit rule that I added (all other changes that I
implemented seem to work correctly):
%.class: $(top_srcdir)/%.java
$(JAVAC) $<
Note: I modified JAVAC to removing the "$(JAVA_SRC)" and/or "@classes"
from the end, changing the command for 'compile-classes' from $(JAVAC)
to "$(JAVAC) $(JAVA_SRC)"
As far as I can tell from reading through the Make info file, this
should have worked.
I'm attatching the diff for the changes I made to lib/Makefile.am in the
hopes that somebody can catch something that I may have missed.
Thanx,
Ian
Index: lib/Makefile.am
===================================================================
RCS file: /gd/gnu/anoncvsroot/classpath/lib/Makefile.am,v
retrieving revision 1.33
diff -r1.33 Makefile.am
14a15
> sinclude $(CLASSES_DEPEND)
106c107
< JAVAC = $(USER_JABBA) $(ARG_CLASSPATH_VM) @KJC_CLASSPATH@:$(USER_CLASSLIB)
$(JAVAC_MAIN) $(ARG_CLASSPATH_JAVAC) .:$(USER_CLASSLIB) -d . @classes
---
> JAVAC = $(USER_JABBA) $(ARG_CLASSPATH_VM) @KJC_CLASSPATH@:$(USER_CLASSLIB)
>$(JAVAC_MAIN) $(ARG_CLASSPATH_JAVAC) .:$(USER_CLASSLIB) -d .
112c113
< JAVAC = @JIKES@ -nowarn +CSO +M +F $(ARG_CLASSPATH_JAVAC)
..:../vm/current:.:@USER_CLASSLIB@ -d . @classes
---
> JAVAC = @JIKES@ -nowarn +CSO +M +F $(ARG_CLASSPATH_JAVAC)
>..:../vm/current:.:@USER_CLASSLIB@ -d .
114c115
< JAVAC = @JIKES@ -nowarn +CSO +M +F $(ARG_CLASSPATH_JAVAC) ..:../vm/current:. -d .
@classes
---
> JAVAC = @JIKES@ -nowarn +CSO +M +F $(ARG_CLASSPATH_JAVAC) ..:../vm/current:. -d .
118c119
< JAVAC = $(USER_JABBA) $(ARG_CLASSPATH_VM) $(USER_CLASSLIB) $(JAVAC_MAIN)
$(ARG_CLASSPATH_JAVAC) .:$(USER_CLASSLIB) -d . $(JAVA_SRCS)
---
> JAVAC = $(USER_JABBA) $(ARG_CLASSPATH_VM) $(USER_CLASSLIB) $(JAVAC_MAIN)
>$(ARG_CLASSPATH_JAVAC) .:$(USER_CLASSLIB) -d .
197c198
< glibj.zip: classes compile-classes $(MAKEFILE_DEPEND)
---
> glibj.zip: classes $(CLASSES_DEPEND) $(CLASSES)
215c216
< $(JAVAC)
---
> $(JAVAC) $(JAVA_SRCS)
272a274,276
>
> %.class: ${top_srcdir}/%.java
> $(JAVAC) $<
