[kaffe] 1.1.0 on mips-linux - new JIT memory problem?
Kevin D. Kissell
kevink at mips.com
Tue Jun 10 07:51:01 PDT 2003
With ./configure --with-engine=intrp, we get
====================
All 137 tests passed
====================
With the default configuration, which is jit3, however,
HelloWorldApp.class.save and CatchLimits.class.save
passe the "make check", but the local compilation of
almost all the regression tests results in a systematic series
of java/lang/OutOfMemoryError failures, e.g.
error compiling:
Internal error: caught an unexpected exception.
Please check your CLASSPATH and your installation.
java/lang/OutOfMemoryError
at java.util.HashMap.rehash(HashMap.java:236)
at java.util.HashMap.put(HashMap.java:136)
at java.util.Hashtable.put(Hashtable.java:109)
at java.lang.System.initProperties(System.java:native)
at java.lang.System.<clinit>(System.java:43)
at java.lang.ClassLoader.<init>(ClassLoader.java:114)
at java.security.SecureClassLoader.<init>(SecureClassLoader.java:20)
at kaffe.lang.AppClassLoader.<init>(AppClassLoader.java:238)
at kaffe.lang.AppClassLoader.<clinit>(AppClassLoader.java:37)
TestScript: line -43: 12762 Aborted (core dumped) /home/kevink/Java/kaffe/kaffe-1.1.0/kaffe/kaffe/kaffe-bin
at.dms.kjc.Main -classpath ".:.::.:/home/kevink/Java/kaffe/kaffe-1.1.0/libraries/javalib/kjc.jar" -d . ./HelloWorldApp.java
FAIL: HelloWorldApp.java
The system is thrashing itself to death - one can feel it
in the interactive responses, as well as see it with "top".
Oddly enough,. TestFloatDouble do ThreadStop *do*
succeed in compiling, and both tests pass, for a total of
4 tests passing out of 137 (those two, plus the ones based
on "save" classfiles). That's quite different behavior
than I've seen previously in MIPS/Linux/kaffe JIT builds.
I hacked TestScript to explicitly have kaffe ask for -mx 256M
(I've only got 64M on my platform), but that did nothing to
improve things. Maybe they would all run on a platform
with infinite memory, but this problem never existed in any
of the 1.0.7-based source trees I've used. I hadn't noticed
any changes going into the MIPS-specific JIT code lately,
so I strongly suspect that there is a problem in the common
kaffe jit3 code that is being manifested for MIPS, and which
could be manifesting iteself of other architectures.
This may be related to the probelm Greg Wooledge reported.
It might be interesting to repeat his freenet test with an
interpretive x86 build. In any case, I cannot recommend
this JIT configuration for performance reasons. ;o)
Is there some easy way to rig it so that the default engine
is platform-dependent, and mips gets intrp by default, but
jit3 if one specifically requests it in ./configure?
There is also an interesting artifact of the ./configure process:
checking asm/signal.h presence... yes
configure: WARNING: asm/signal.h: present but cannot be compiled
configure: WARNING: asm/signal.h: check for missing prerequisite headers?
configure: WARNING: asm/signal.h: proceeding with the preprocessor's result
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: ## Report this to bug-autoconf at gnu.org. ##
configure: WARNING: ## ------------------------------------ ##
checking for asm/signal.h... yes
There's nothing obviously wrong with signal.h that either I nor gcc can see.
Regards,
Kevin K.
More information about the kaffe
mailing list