libgcj performance: _Jv_LookupInterfaceMethod

[Tom Tromey]

>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Following up on my libgcj performance issues last week... I've
Jeff> narrowed Rewriting these two methods solves the problem.  My
Jeff> gcj-compiled program now outperforms the JIT compiler.  It runs
Jeff> literally twice as fast as before.  I wonder if others weren't
Jeff> having the same problem?

I'm checking in a modified version of this patch.  Basically I'm
cleaning up formatting problems.  In the future please make sure the
formatting matches our coding style, and please write a ChangeLog
entry.  Thanks in advance.

Jeff> !   if (method_cache_count > MCACHE_SIZE*2/3)
Jeff> !     {
Jeff> !       for (int i = 0; i < MCACHE_SIZE; i++)
Jeff> !       method_cache[i].klass = 0;
Jeff> !     }
Jeff> ! 
Jeff> !   for (int index = method->name->hash % MCACHE_SIZE;
Jeff> !        method_cache[index].klass != NULL;
Jeff> !        index = (index+1) % MCACHE_SIZE)
Jeff> !     {
Jeff> !       method_cache[index].method = method;
Jeff> !       method_cache[index].klass = klass;
Jeff> !     }

I think adding a ";" after the for loop would be a sufficient change.
This (old code) sets each non-empty hash slot to the new method.  It
is probably intended to just set the next empty hash slot.

However, I think your change is ok.  I'd want to see data supporting a
loop before we restored it.  For instance, if hash value clashes are
common, then adding the loop back would make sense.

Tom