[RFC/RFT] Patch (java): Switch to new verifier

[Bryce McKinlay]

Tom Tromey wrote:

>Ranjit> The attached patch proposes to switch GCJ to use the new
>Ranjit> verifier.
>
>I think this isn't safe, because vfy_is_assignable_from assumes that
>we are generating type assertions.  With the C++ ABI, this is not the
>case.
>  
>
We just need to implement a static assignability check here for the 
!flag_indirect_dispatch case. This turns out to be pretty easy:

--- verify-glue.c       19 Feb 2005 01:14:17 -0000      1.4
+++ verify-glue.c       3 Mar 2005 23:58:12 -0000
@@ -231,17 +231,18 @@
 bool
 vfy_is_assignable_from (vfy_jclass target, vfy_jclass source)
 {
-  /* At compile time, for the BC-ABI we assume that reference types are 
always
-  compatible.  However, a type assertion table entry is emitted so that the
-  runtime can detect binary-incompatible changes.  */
-
-  /* FIXME: implement real test for old ABI.  */
-
   /* Any class is always assignable to itself, or java.lang.Object. */
   if (source == target || target == object_type_node)
     return true;
 
-  /* Otherwise, a type assertion is required.  */
+  /* For the C++ ABI, perform this test statically. */
+  if (! flag_indirect_dispatch)
+    return can_widen_reference_to (source, target);
+
+  /* For the BC-ABI, we assume at compile time that reference types are 
always
+  compatible.  However, a type assertion table entry is emitted so that the
+  runtime can detect binary-incompatible changes.  */
+
   add_type_assertion (current_class, JV_ASSERT_TYPES_COMPATIBLE, source,
                      target);
   return true;

>Also, I suspect that the new verifier generates typemaps that require
>special treatment by subsequent code-generation passes.  There are
>hacks in place for this, but I'm not sure they work when compiling
>with the C++ ABI.
>  
>
Andrew may correct me, but I don't recall anything we did for the new 
verifier that will be incompatible with the C++ ABI. It does seem to 
work ok on my (very brief) testing. It would be nice to get rid of the 
old verifier - there's no point keeping it around if the new one can be 
made to work.

Bryce