This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[RFC/RFT] Patch (java): Switch to new verifier
- From: Ranjit Mathew <rmathew at gmail dot com>
- To: GCJ Patches <java-patches at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 28 Feb 2005 00:20:21 +0530
- Subject: [RFC/RFT] Patch (java): Switch to new verifier
Hi,
The attached patch proposes to switch GCJ to use the new
verifier. If approved and found to be reliable enough (please
help test), I'll submit a patch to remove the then redundant
old verifier code separately.
I have tested this on i686-pc-linux-gnu, Jacks included, and
I get no new failures, but I do get:
XPASS: pr13107_2 compilation from bytecode
XPASS: pr13107_2 -O3 compilation from bytecode
XPASS: pr13107_3 compilation from bytecode
XPASS: pr13107_3 -O3 compilation from bytecode
In the Mauve verifier testsuite, I see an improvement
of FAILs from 35 to just 15. I do see an "interesting"
failure here though (glibc 2.3.4):
/extra/src/verify/build > $MYGCJ -c locals/fail/toofew.class
locals/fail/toofew.j: In class 'locals.fail.toofew':
locals/fail/toofew.j: In method
'locals.fail.toofew.doit(java.lang.String[])':
locals/fail/toofew.j:0: error: verification failed: invalid local variable
*** glibc detected *** free(): invalid pointer: 0x084d7740 ***
locals/fail/toofew.j:0: confused by earlier errors, bailing out
FWIW, the new verifier does seem a bit slower than
the old one, but it sure is a *lot* more comprehensive and
correct in a lot of cases.
Without the change to build_java_array_length_access, I get
a FAIL in the "Array_3 -O3 bytecode -> native" test. You can
see it even now by using -findirect-dispatch with a method
like:
int foo( )
{
int[] x = (int[] )null;
int y = x.length;
return 666;
}
At -O3, the "y = x.length" part seems to be thrown away
even though it could SEGFAULT. Whether this is a fault
of the front-end or the middle-end or whatever, we seemed
to have a special case to handle it explicitly and
for some reason, we were disabling it for the new verifier.
OK for mainline?
Thanks,
Ranjit.
--
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
Index: ChangeLog
from Ranjit Mathew <rmathew@hotmail.com>
Switch to new verifier.
* lang.c (flag_new_verifier): Set to 1.
* expr.c (build_java_array_length_access): Remove !flag_new_verifier
for known NULL array length access.
Index: lang.c
===================================================================
--- lang.c 2005-02-27 19:20:39.000000000 +0530
+++ lang.c 2005-02-27 20:29:57.000000000 +0530
@@ -140,7 +140,7 @@ int flag_deprecated = 1;
int flag_verify_invocations = 0;
/* True if the new bytecode verifier should be used. */
-int flag_new_verifier = 0;
+int flag_new_verifier = 1;
/* When nonzero, print extra version information. */
static int v_flag = 0;
Index: expr.c
===================================================================
--- expr.c 2005-02-27 19:20:27.000000000 +0530
+++ expr.c 2005-02-27 21:09:46.000000000 +0530
@@ -818,7 +818,7 @@ build_java_array_length_access (tree nod
throws a NullPointerException. The only way we could get a node
of type ptr_type_node at this point is `aconst_null; arraylength'
or something equivalent. */
- if (!flag_new_verifier && type == ptr_type_node)
+ if (type == ptr_type_node)
return build3 (CALL_EXPR, int_type_node,
build_address_of (soft_nullpointer_node),
NULL_TREE, NULL_TREE);