[kaffe] More mipsel jit3

Kevin D. Kissell kevink at mips.com
Mon Mar 8 23:59:01 PST 2004


> >>>>> "Casey" == Casey Marshall <rsdio at metastatic.org> writes:
> 
> Yeah, ok, I was pretty wrong with the implementations of fcmpl and
> friends. I think I have it sorted now.

One question about that:  Did you implement those operations because
you thought it would be good for performance, or did you have the
impression that the JIT was failing because of their absence?  They
did not seem to be broken when I was working on jit3 under 1.0.7/1.0.8.
There are a number of possible jit3 optimizations for MIPS that I noted
when I was working on it (though of course I no longer remember what
they were- sigh), but I'd suggest getting things working correctly before
launching into any optimization campaign!

> But now my problem appears to be that soft_anewarray is being called
> with an uninitialized class, which is supposed to be
> java.util.HashMap$HashEntry. Any ideas of why this would happen?

Hmm.  That sounds familiar.  When you say "uninitialized class", 
do you mean a completely uninitialized class, or an incompletely intialized 
one that contains a null pointer?

When I was wrenching on 1.0.7/1.0.8 trying to get the JIT to work,
the system built and ran all but 4 of the regression tests (though note
that, at the time, kaffe didn't use itself to compile the regression tests
as it does now, so I don't know if the JITted compiler was functional).
I spend a couple of days digging through the rubble of the failures with
gdb and trace output.  What appeared to be happening in most, if not
all cases was that the generated code was dereferencing what should
have been an initialized pointer field in an internally generated data
structure, but getting a zero pointer.  But it wasn't as if the rest of the
data structure was uninitialized - at least, it wasn't zero, and looked
superficially sane. Since a lot of stuff worked just fine, I figured that 
maybe there was some low-probability path through the code that was
invoking an operation that wrote through to memory as a side-effect
on x86, but which stayed in a register on MIPS.  If that's the sort of thing 
that's happening, the question would be whether the kaffevm/jit3 code 
is broken because it's making an illegal assumption, or whether the MIPS 
code is broken because it's making an illegal optimization.

Looking back over my archives, I note that Kapil Vaswani was
trying to get jit3 to work on Alpha last April, and was getting similar
error messages to what I was seeing in the crashes I described above.
If the Alpha JIT is now working correctly, you might what to take a
look at the CVS log of the Alpha tree to see if some change has an
analogy in MIPS.

            Regards,

            Kevin K.





More information about the kaffe mailing list