[11/18/97 cskim]
Customer is using the JDK 1.1.3A & 1.1.3D.
The following attached test case gets an assertion error in our port
of the JIT, at line 57 of patch.c, and I think the JIT is at fault.
I believe the problem is connected with our building the JIT with
-DExplicitChecks. The JIT's actions for opcode opc_getfield_quick_w
are to do the j86CompileTimeAdrQ test, which fails in this case,
then to call j86CreatePatch to create a patch for the method.
Then it subsequently calls j86FieldRef. This will release the patch
(by setting mi->patch to Null) at the end ... but first it calls j86GetHandle.
This, only when -DExplicitChecks is on, will call j86ThrowException, which
calls j86SetExitContext, which itself needs a patch and calls j86CreatePatch -
but the first patch created above is still there, and thus the assertion
check in j86CreatePatch fails.
Is it possible that this bug has escaped notice so far because you always
build with the signal handling implementation of null reference checks,
rather than ExplicitChecks? Also, if the assertion check is left out
(e.g. java rather than java_g is run), the test case executes as expected.
class A {
int x;
};
public class nil {
static int f(A a) {
return a.x;
}
public static void main(String[] args)
{
f(null);
}
}
Customer is using the JDK 1.1.3A & 1.1.3D.
The following attached test case gets an assertion error in our port
of the JIT, at line 57 of patch.c, and I think the JIT is at fault.
I believe the problem is connected with our building the JIT with
-DExplicitChecks. The JIT's actions for opcode opc_getfield_quick_w
are to do the j86CompileTimeAdrQ test, which fails in this case,
then to call j86CreatePatch to create a patch for the method.
Then it subsequently calls j86FieldRef. This will release the patch
(by setting mi->patch to Null) at the end ... but first it calls j86GetHandle.
This, only when -DExplicitChecks is on, will call j86ThrowException, which
calls j86SetExitContext, which itself needs a patch and calls j86CreatePatch -
but the first patch created above is still there, and thus the assertion
check in j86CreatePatch fails.
Is it possible that this bug has escaped notice so far because you always
build with the signal handling implementation of null reference checks,
rather than ExplicitChecks? Also, if the assertion check is left out
(e.g. java rather than java_g is run), the test case executes as expected.
class A {
int x;
};
public class nil {
static int f(A a) {
return a.x;
}
public static void main(String[] args)
{
f(null);
}
}