This is the mail archive of the 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]

Re: type check overhead (performance...)


please excuse if the 'performance' discussion turns up again. With my
new libpthreads, I'm quite happy with gcj/libgcj performance (but now 
I would like to gcj-compile Java 1.1. internal classes and anoymous 


Kresten Krab Thorup wrote:

> With a dynamic compiler that does code-specialization, mosts of such
> casts can be eliminated.  
> In context of static compilation, I expect that we could get a
> significant win by just adding a mono-morphic inline cache.  That is,
> for each expression at the form 
> x = (Foo) y;
> we'd generate code like:
> static _Jv_VTable* __tmp = 0;
> if (y->vtable != __tmp)
>   {
>      _Jv_CheckArrayStore (y, Foo.class); // may throw exc
>      __tmp = y->vtable;
>   }
> x = y;   

It would be fine if this works. However, my original point was that most
java.util data-structures use plain java.lang.Object and not Foo:

  Something  z;
  Foo        f[] = new Foo[42]; 
  Object     o[] = new Object[42];

  f[1] = (Foo) z;      // potentially difficult to resolve, might be slow

  o[2] = (Object) z;   // works for everything except elementary data types,
                       // and should be fast

  o[3] = o[2];         // this is the same as o[3] = (Object) o[2];
                       // and should be fast

Perhaps you could just optimize the store-into-Object and store-into-Object[]


And Martyn Pearce wrote:

> Might be worth a peek at Martin Odersky's GJ,
>, which provides a Java superset
> with "generics" (read: C++ templates), and provides annotiations within
> the class files enabling a suitable VM to know of such uses.

If I remember correctly, Pizza uses the C++ approach - the compiler
generates one class per type combination like List<String>, List<Object>, 
... which results in a potentially very large number of classes, and still 
has the 'isAssignableFrom' runtime problem.

GJ, on the other hand, generates one class per data structure and uses
runtime type casts (and clever checks to guarantee that the casts won't
fail later).

Please tell me, if there actually exists a JVM somewhere that avoids or
speeds up the runtime checks somehow...


- Norman

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