This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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);

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]