This is the mail archive of the java@gcc.gnu.org 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]
Other format: [Raw text]

Re: New ABI progress report


Bryce McKinlay writes:
 > On Oct 10, 2003, at 7:17 AM, Andrew Haley wrote:
 > 
 > > One bad thing about indirect dispatch as it stands is the way that we
 > > do a lot of linear searches through tables when resolving references.
 > > If er're serious about making indirect dispatch the default case,
 > > we'll have to fix this.  I'm thinking that the compiler will have to
 > > build hash tables for methods and field names, or perhaps aoutput a
 > > sorted list ofnames.
 > 
 > These are all Utf8Consts, so the compiler emits hash keys for them 
 > anyway. So, its pretty quick to determine by the keys that each string 
 > probably isn't the one being looked for. If this does turn out to be a 
 > performance problem, the runtime can simply build a hash table on the 
 > fly using the existing keys - no need for the compiler to emit anything 
 > extra. It would certainly be beneficial to do this for resolving 
 > classes, but I'm not so sure about the individual members within each 
 > class - as there is a size trade off to building the tables.

Something like the ELF hash table can be made pretty small.  I'd like
us to get to the situation where there are no performance advantages
to the traditional way of doing things.  

The goal IMO should be that we get from a name to a method reference
in O(1) time.  But as long as the performance is basically reasonable
that'll do for 3.4.

 > Sorting and binary-searching would work too, but it would affect things 
 > like reflection and serialialization UID compatibility.

No necessarily; it depends how we do it.

Andrew.


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