Kaffe/Alpha

[Patrick Tullmann]

abnay at altavista.com wrote:
> On Wed, 06 September 2000, Patrick Tullmann wrote:
> > Okay, so its not a JIT-specific problem.  Can you run with '-vmdebug
> > GCDIAG' on the interpreter and give me a backtrace to the problem from 
> > GDB?  
> 
> Here it is:
> 
> user at hostname:~/kaffe-1.0.6% kaffe -vmdebug GCDIAG test/regression/HelloWorldApp.java 
> [...]
> #6  0x2000014606c in jmalloc (sz=6) at gc.c:21
> #7  0x2000014218c in findClassInJar (cname=0x120205e30 "java/lang/Short.class", einfo=0x11ffff840)
>     at findInJar.c:221

Okay, so it blows up in the same place with and without GCDIAG, so its 
probably something that happens immediately before loading
java.lang.Short.   This stuff is happening before locking or threads
are set up, so its not one of those problems.  The nice thing about no 
threads, is that this should be a deterministic problem.  :)

The class loaded immediately before java.lang.Short is
java.lang.Character which is a rather large and complicated class.
However, it isn't brought beyond CSTATE_LINKED, so much of the
complexity isn't touched.

At this point, I think someone is going to have to really run the
debugger on this and figure out what's changing in the GC block.  It
could be the jar-parsing code (test by un-jar'ing Klasses and looking
up only uncompressed files) or the class parsing code.

Sorry there wasn't a simple fix.

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann at cs.utah.edu
 Indifference may cause the downfall of mankind, but who really cares?