This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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]

Re: Java: [BC] Implement type assertion table


Tom Tromey wrote:

I tried out the type assertion patch today.

Bryce> +bool
Bryce> +vfy_is_assignable_from (vfy_jclass target, vfy_jclass source)
Bryce> +{
[ ... ]
Bryce> +  /* Any class is always assignable to itself, or java.lang.Object. */
Bryce> +  if (source == target || target == object_type_node)
Bryce> +    return true;

We can do further optimizations in the case of arrays. An array is
always assignable to Serializable or Cloneable, and never assignable
to anything other than Object or another array type. Likewise,
non-arrays are never assignable to an array type.


Hmm. I suspect most of these assertions would not actually occur in practice, though, unless perhaps we are compiling illegal bytecode. ie: assignment of an array to a non-Object type would be an error at compile time, and, AFAIK, an array type can't possibly change at runtime to a non-array.

On the subject of arrays, I saw a crash running Eclipse because the
assertion table held some array types, but link.cc isn't ensuring that
all the necessary supers are installed.  (Actually linking seems to be
a problem in general.)  I have a runtime patch for this, but it seems
to me that if we stripped off the arrays in the compiler we could
probably improve the chances of sharing entries (and utf8consts) and
potentially reduce the size of the table.

So, if we have, say, a Foo[] being assigned to a Bar[], we strip off the array type and just emit Foo->Bar?

On a related note, I was wondering about the use of class signatures rather than regular class names in the assertion table. Using class names instead would definitely increase Utf8Const sharing. Im not sure why the signature is used but thought it prudent to leave it that way for now. Andrew, does this ring any bells from when you wrote the "__verify" code?

Regards

Bryce


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