libgcj performance: _Jv_LookupInterfaceMethod

Mon Nov 22 16:13:00 GMT 1999

Jeff Sturm <jsturm@sigma6.com> writes:
> That's right... what I found however is that a complete byte-for-byte
> comparison is done on most invocations, so that more time is spent in
> the _Jv_equalUtf8Consts method than any other, overall. The runtime
> would do far better if all strings constants were intern'ed somehow.

(1) This was discussed not too long ago on this list. One of my points
was that if are going to consider true interning of Utf8Consts, you
might instead consider dropping Utf8Consts entirely, and just using
(interned) String objects. (That would be a preliminary first step
in a possible merger of JvField and java.lang.reflect.Field, and
likewise JvMethod and java.lang.reflect.Method.)
(2) It is also possible to do *partial* interning. True interning
(as in String's intern method) requires that one *guarantees* that
equal strings have the same address. However, if *most* strings
are interned, that we can detect equality fast (in most cases) by
comparing the addresses, and detect inequality fast by check hash values.
(3) However, I don't think optimizing Utf8Const equality testing
is the best way to speed up _Jv_LookupInterfaceMethod (as you
seem to agree). Godmar seems to have gotten the basic algorithms
for constant-time interface lookup working in the context of the Kaffe
run-time; we can do the same in libgcj. This means building the
neccesary tables at class initialization time (rather than a mix of
compile time and init time), and re-writing _Jv_LookupInterfaceMethod
to use those tables. Once that is working, *then* we can have
the compiler build the tables and possibly inline _Jv_LookupInterfaceMethod.
(The work in building the tables at run-time would not be wasted,
as you would still need it for dynamically loaded classes.)
I think that is easier and more productive than trying to intern
Utf8Consts, which is non-trivial.
> I also experimented with a small patch (below) that cuts down the string
> compare times drastically in some programs. Specifically, for Bryce's
> simple benchmark it cuts the time spent in interface calls roughly in
> half, at the cost of slightly higher memory utilization.
>> (I know the real solution is better compiler support for interfaces... I
> was just considering interim solutions.)

I don't object to interim solutions ...
-- 
	--Per Bothner
per@bothner.com http://www.bothner.com/~per/