Re: why it is impossible for the jit to use a global codeinfo

Date view Thread view Subject view Author view

From: Tim Wilkinson (tim@transvirtual.com)
Date: Thu Dec 10 1998 - 18:03:57 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.

Tim

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


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:11 EDT