From: Godmar Back (gback@marker.cs.utah.edu)
Date: Thu Dec 10 1998 - 23:55:48 EST
Okay, since we've now got a reentrant verifier, couldn't we make
sure that we will not have to enter the translator after verification.
Consider how the jitter is reentered: it's because a call to getClass,
say for a NEW instruction, causes a call to loadClass.
Basically, split translate in two parts, a reentrant part and a
non-reentrant part. The reentrant part would involve the call to
verifyMethod (which is reeentrant) and the non-reentrant part would
involve the actual compilation & code emission.
What if we made sure that all classes were loaded during verification.
We would have to identify those instructions in kaffe.def that may
result in the execution of Java code and thus in the invocation of
the jitter.
Then, we'd we add case:s for them in the verifier while it's safe.
I see one big potential problem with this approach:
Since the verifier scans code linearly, we might eagerly load and/or
initialize classes that we would not have otherwise.
For instance, in
if (random()) {
X.a = 1;
} else {
Y.a = 2;
}
we should load, link, and initialize either class X or Y, but never both.
Now there's two things: if we were so eager as to actually invoke
the static initializers of X and Y, i.e., initialize them, we'd be
certainly wrong. However, if we merely invoked loadClass() on a
classloader, i.e., loaded and linked the class, we might still be
wrong, but maybe not as wrong. We'd be wrong because we invoked
loadClass when we shouldn't have. But then, consider how loadClass
is typically written.
However, if the class loader got the class from findSystemClass,
it would be initialized. That would then be wrong too, but it
likely wouldn't matter.
Now I realize that I'm contradicting myself somewhat here and am
proposing another "fix the symptoms" solution.
Any comments?
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:11 EDT