New ABI progress report

Thu Oct 9 21:35:00 GMT 2003

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.
Sorting and binary-searching would work too, but it would affect things 
like reflection and serialialization UID compatibility. Not that we are 
really compatible anyway, but...
> There is still some tidying and bug fixing to do, of course.
>> I think we should have reasonably decent support in 3.4.

Cool.
Bryce.