Re: Alpha vs. new ABI

[Jeff Sturm <jeff dot sturm at commerceone dot com>]

Tom Tromey wrote:
> With your patch we'll have just the vtable slot (a pointer) and the
> array length slot (a 32-bit int).  On x86 this means we'll never need
> any padding.  On alpha we'll still need 4 bytes padding for doubles.

And jobject and jlong too.  At least the former is quite common.

> The data for an array has to be aligned (at least) according to its
> type.  Right now in some scenarios the compiler and the runtime
> disagree about this alignment, resulting in chaos.  For instance,
> right now this causes `hello, world' to fail on the alpha, because
> there are an extra 4 bytes of padding that the runtime doesn't expect.

It appears that the C++ compiler changed its member alignment rules, perhaps in
conjunction with the new ABI.  I can't find any fault with the runtime proper;
the problem starts with those portions of the runtime that are compiled by C++.

> I still prefer the solution of minimizing space wastage and giving the
> `data' member natural alignment for its type.  However I'm amenable to
> any solution that actually works, especially given that we don't have
> hard data on the tradeoffs involved.  We're going to break binary
> compatibility any number of times.  If we make a bad choice here, we
> can change it.

The last I heard, Alex seemed to be leaning towards just making the java and cp
frontends agree on JArray alignment, instead of forcing something.  His untested
patch <uri:http://gcc.gnu.org/ml/java/2001-01/msg00593.html> revealed another
bug in the java frontend however.

Below is what I ended up with.  I'm not very pleased with it because of the side
effects of java_array_type_length() relying on TYPE_MAX_VALUE to remember the
length an array was allocated with.  If we don't suppress building the `data'
field, we end up with TYPE_MAX_VALUE == -2 for unknown array sizes, which just
happens to do the right thing.  (Since java_array_type_length is only a minor
optimization, it could go away, but for static array generation depending on
it.  Ick.)

Anyway, this allows libjava to work on Alpha, though I didn't test on x86:

Index: typeck.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/typeck.c,v
retrieving revision 1.34
diff -u -r1.34 typeck.c
--- typeck.c    2001/01/25 22:25:22     1.34
+++ typeck.c    2001/02/01 20:08:19
@@ -375,7 +375,7 @@
      tree element_type;
      HOST_WIDE_INT length;
 {
-  tree sig, t, fld;
+  tree sig, t, fld, atype, arfld;
   char buf[12];
   tree elsig = build_java_signature (element_type);
   tree el_name = element_type;
@@ -413,39 +413,12 @@
   FIELD_PUBLIC (fld) = 1;
   FIELD_FINAL (fld) = 1;

-  if (length >= 0)
-    {
-      tree atype = build_prim_array_type (element_type, length);
-      tree arfld = build_decl (FIELD_DECL, get_identifier ("data"), atype);
-
-      DECL_CONTEXT (arfld) = t;
-      TREE_CHAIN (fld) = arfld;
-
-      /* We need to force the data field to begin at an alignment at
-       least equal to the biggest alignment in an object type node
-       in order to be compatible with the way that JArray is defined
-       in CNI.  However, we can't exceed BIGGEST_FIELD_ALIGNMENT. */
-      {
-      unsigned desired_align = TYPE_ALIGN (object_type_node);
-      desired_align = MAX (desired_align, TYPE_ALIGN (element_type));
-#ifdef BIGGEST_FIELD_ALIGNMENT
-      desired_align = MIN (desired_align,
-                           (unsigned) BIGGEST_FIELD_ALIGNMENT);
-#endif
-#ifdef ADJUST_FIELD_ALIGN
-      desired_align = ADJUST_FIELD_ALIGN (fld, desired_align);
-#endif
-      DECL_ALIGN (arfld) = desired_align;
-      }
-    }
-  else
-    {
-      unsigned desired_align = TYPE_ALIGN (element_type);
-#ifdef BIGGEST_FIELD_ALIGNMENT
-      desired_align = MIN (desired_align, (unsigned) BIGGEST_FIELD_ALIGNMENT);
-#endif
-      TYPE_ALIGN (t) = desired_align;
-    }
+  atype = build_prim_array_type (element_type, length);
+  arfld = build_decl (FIELD_DECL, get_identifier ("data"), atype);
+  DECL_CONTEXT (arfld) = t;
+  TREE_CHAIN (fld) = arfld;
+  DECL_ALIGN (arfld) = TYPE_ALIGN (element_type);
+  /* TYPE_ALIGN (t) = TYPE_ALIGN (element_type); */

   /* We could layout_class, but that loads java.lang.Object prematurely.
    * This is called by the parser, and it is a bad idea to do load_class

--
Jeff Sturm
jeff.sturm@commerceone.com