Eats up whole memory on ARM while compiling GNU Classpath
Brought to you by:
cabbey,
daveshields
Menu
▾
▴
#895 Eats up whole memory on ARM while compiling GNU Classpath
On ARM, while compiling GNU Classpath, Jikes eats up all available memory and gets killed by OOM killer.
This bug has been confirmed to exist in versions 1.18 and 1.19. Please see:
For details.
This bug effectively prevents using Jikes on ARM to build classpath for any free JVM (most of them base their classpaths on GNU Classpath).
Submitter: Grzegorz B. Prokopski <gadek@debian.org>
Given that the problem only seems to exist on ARM, and I gave away my RiscPC several years ago, can someone try to get a backtrace of where this is happening? Presumably it takes long enough to exhaust memory that you can kill it and get a core dump?
It still exists in Jikes CVS as of 22/05/2004
If you want to try debugging it, there are freely accessible arm-linux machines setup by the handhelds.org developers. See
http://www.handhelds.org/projects/devcluster.html for details
Dalibor Topic
after compiling jikes on an iPaq (!), here are a couple of telling backtraces [why the submitter couldn't have done this, i don't know]:
(gdb) bt
#0 0x000edd60 in ULongInt::operator< (this=0xbfffe68c, op=
{<BaseLong> = {value = {double_value = 1.7763566970825233, words = 74087951349}}, <No data fields>}) at long.cpp:399
#1 0x000b6008 in IEEEdouble::Ratio (a=@0xbfffe8e4, b=@0xbfffe904)
at double.cpp:2245
#2 0x000b47ec in IEEEdouble::IEEEdouble (this=0xbfffeb9c,
str=0x5f4378 "2.718281828459045", check_invalid=true) at double.cpp:1962
#3 0x000f37e8 in DoubleLiteralTable::FindOrInsertDouble (this=0x204718,
literal=0x5fa8d8) at lookup.cpp:1147
#4 0x000cc130 in Semantic::ProcessDoubleLiteral (this=0x5e1510, expr=0x246f18)
at expr.cpp:2744
#5 0x000306d4 in Semantic::ProcessExpression (this=0x5e1510, expr=0x246f18)
at semantic.h:1232
#6 0x000ca424 in Semantic::ProcessExpressionOrStringConstant (this=0x5e1510,
expr=0x246f18) at expr.cpp:2017
#7 0x000de124 in Semantic::ProcessVariableInitializer (this=0x5e1510,
variable_declarator=0x246f2c) at init.cpp:37
#8 0x0009183c in Semantic::InitializeVariable (this=0x5e1510,
field_declaration=0x246f48, init_method=0x5a52f8) at decl.cpp:3973
#9 0x00091e84 in Semantic::ProcessStaticInitializers (this=0x5e1510,
class_body=0x5dff38) at decl.cpp:4163
#10 0x00088618 in Semantic::CompleteSymbolTable (this=0x5e1510,
class_body=0x5dff38) at decl.cpp:1397
(gdb) bt
#0 0x4005f2dc in __builtin_new () from /usr/lib/libstdc++-libc6.2-2.so.3
#1 0x4005f770 in __builtin_vec_new () from /usr/lib/libstdc++-libc6.2-2.so.3
#2 0x000bc5f4 in BigInt::resize (this=0xbfffe904, k=0) at double.h:717
#3 0x000bc590 in BigInt::BigInt (this=0xbfffe904, i=1) at double.h:707
#4 0x000b41c8 in IEEEdouble::IEEEdouble (this=0xbfffeb9c,
str=0x5f4378 "2.718281828459045", check_invalid=true) at double.cpp:1885
#5 0x000f37e8 in DoubleLiteralTable::FindOrInsertDouble (this=0x204718,
literal=0x5fa8d8) at lookup.cpp:1147
#6 0x000cc130 in Semantic::ProcessDoubleLiteral (this=0x5e1510, expr=0x246f18)
at expr.cpp:2744
and indeed, this source:
class Bug3973 {
double d = 2.718281828459045;
}
produces the same effect:
(gdb) bt
#0 0x4005f874 in __builtin_vec_new () from /usr/lib/libstdc++-libc6.2-2.so.3
#1 0x01408eb8 in ?? ()
#2 0x000bc30c in BigInt::BigInt (this=0xbfffe8e8, op=@0xbfffe908)
at double.h:628
#3 0x000b4140 in IEEEdouble::IEEEdouble (this=0xbfffeb40,
str=0x5f41a8 "2.718281828459045", check_invalid=true) at double.cpp:1883
#4 0x000f37e8 in DoubleLiteralTable::FindOrInsertDouble (this=0x2046f8,
literal=0x240550) at lookup.cpp:1147
#5 0x000cc130 in Semantic::ProcessDoubleLiteral (this=0x236920, expr=0x236538)
at expr.cpp:2744
There are a couple of problems here. One is an infinite loop that we don't seem to break out of on ARM, the other is that many of our overloaded operators are wrongly implemented (obvious here because we can see them leak all available memory).
I seem to have fixed the operators; this bug should now be retitled "eats up whole CPU on ARM while compiling double literal" ;-)
So now we're back to the infinite loop in IEEEdouble::IEEEdouble, a 614-line (!) function.
I've just fixed a bug in SableVM that made pretty much all computations in 'double' presision impossible/useless. I think it might be releated problem here, as the stack trace from this bug shows code operating on 'doubles'.
The problem is that ARM stores 'double', which is a 64bit value in a strange manner: the two 32bit parts of this value have exchanged order. That means that if you want to operate directly on bits of a 'double' or you want to store a 'double' in a file - you have to take it into account. I think it might be the cause of the behavior we see here.
HTH
yeah, that was my initial assumption too, based on vague memories from the days in the early 90's when i was an ARM programmer. the code in question, though, is the IEEE emulation code --- we're not using native floating-point.
see the thread on the jikes-dev mailing list from a couple of months ago for more information about what we found.
Logged In: YES
user_id=1420432
I confirm some ARM have WORDS ORDER BIG ENDIAN for IEEE754
double ONLY.
If HAVE_64_BIT_TYPES is defined, the WORDS_BIGENDIAN is
ignored and set the opposite WORD order !
I finally unherit IEEEdouble from BaseLong and introduce a
new flag DOUBLE_WORDS_BIGENDIAN (replace WORDS_BIGENDIAN in
IEEEdouble) that is not ignored when HAVE_64_BIT_TYPES is
defined.
I have managed to compile GNU Classpath with small
modification to
fdlibm (byte order little endian macro StoreInc) and
everything(jamvm 1.4.1,classpath 0.19, jikes 1.22)
goes right (on arm).
But 'run everywhere' seems to be broken :
arm jikes compiled class execute right on 386 java but
386 javac compiled class are interpreted with inversed words
for double (Argh)!
Any clues ?
Want a patch ? (experimental)