From: Godmar Back (gback@cs.utah.edu)
Date: Thu Dec 10 1998 - 18:11:45 EST
>
> Really the cause of re-entry into the jitter is because of too eager class
> loading (resulting in the clinit method being called in loaded classes) - this
> really doesn't need to happen and the class loading need only be taken to the
> CSTATE_LINKED state. Whether that would catch all situations I don't know
> however.
>
Do you recall that we made the class loading actually less eager?
In fact, if I make the class loading more eager, this problem is
less likely to occur, although the resulting behavior is wrong.
In my opinion, it has nothing to do with the <clinit> method.
In fact, I'm not seeing the problem with <clinit>.
Let me try to explain the scenario again:
Suppose you have a classloader that provides a loadClass method.
Suppose that loadClass method invokes another function, which
hasn't been jitted. So, when loadClass is called, the trampoline
is hit, and the jitter is invoked. So far with me?
Now this assumes that we weren't in the jitter when we called loadClass,
correct? However, we have no way of preventing that since the
jitter must call verifyMethod, and verifyMethod may call getClass,
which may call loadClass, getting us into that scenario. There's no
way around that.
Now, when class loading was eager, these calls by the verifier to
getClass less often resulted in calls to loadClass, because all the
classes were already there and so we could just take them from the
centry. However, even in that case, example can be constructed
where that was wrong. So making class loading eager is no help.
If you need a test case to see this, let me know (the one I'm currently
working with shows it, but is somewhat involved.)
- Godmar
> Godmar Back wrote:
>
> > Well, I'm fixing the classloader problems people have been reporting
> > lately, and I got the interpreter done (along with a bunch of other
> > bug fixes; did you know, for instance, that Kaffe's interpreter didn't
> > even release a lock on a synchronized method when an exception was thrown).
> >
> > While pondering the jitter, I've come to the conclusion that it is
> > impossible to not have verifyMethod reentrant, i.e., that it is necessary
> > to carry codeInfo along.
> >
> > Consider a scenario where a method is verified, the jit lock is taken
> > and then getClass is invoked. GetClass, as it so happens, calls out
> > to loadClass. loadClass needs to jit compile something and can't, and
> > voila we have the infamous "reenter verifier violation"
> >
> > So, I'm trying to make this work with the fewest changes possible.
> > In code-analyse.c, it's easy. It's harder in the jit/ subdirectory.
> > I think in order to keep the code changes small, I'll just use a
> > thread-local variable there.
> >
> > Any comments?
> >
> > - Godmar
>
>
>
> --
> Tim Wilkinson Tel: +1 510 704 1660
> Transvirtual Technologies, Inc., Fax: +1 510 704 1893
> Berkeley, CA, USA. Email: tim@transvirtual.com
>
>
>
>
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:11 EDT