Alpha vs. new ABI

Thu Feb 1 12:32:00 GMT 2001

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
