[Mono-dev] Patch: Fast virtual generic method calls

[Mark Probst]

Hi Rodrigo,

> Makes sense, the space is already these. Does it handle dispatching of
> interface generic methods? The code in method-to-ir.c suggests not.

No, it doesn't.  I don't think interfaces should be too hard, though.
All we need to do is to pass the fully instantiated MonoMethod* as the
key.  Not sure how this plays together with non-generic interface
methods, though.

> Since you have a hashtable with the expansions, what about introducing a
> limit
> on the number of trunks per method, this change should not be hard.

What would it buy me, though?  I'd suggest, without any hard data,
that methods with more instantiations are more heavily used, so
limiting them doesn't make much sense.  Unless we use an LRU schema
for selecting which instantiations make it into the thunk, but I think
that can easily lead to thunks which are constantly re-compiled
because the "working set" changes periodically.

> Have you thought about using something else than a MonoMethod as key?

Actually, the key is not the MonoMethod but the method_inst.

> Right now it's only possible to share if all instantiations are reference
> types. I guess we
> can determine if the method is shareable on first compilation, which is
> before any trunk code
> is generated.
>
> Given that we know this, we could store in the upper bit of the tokens used
> for resolving the trunk
> if they refer to a sharable instantiation. Then on trunk code, if the method
> is sharable
> we check this bit and avoid generating tons of trunks.

Whether the method is sharable can be determined in the thunk-table
builder, as well.  However, there's no point in doing that because
unfortunately we can't use one thunk entry for all shared
instantiations.  It's true that those instantiations share the same
native code, but on the other hand, each of them needs to be passed a
different MRGCTX.  This is currently implemented by jumping not to the
method directly but to a static RGCTX invoke wrapper for the method,
which passes the MRGCTX.

> But even with that we would still need to generate trunks. If we generate
> then partially, as you suggest,
> for each decision node, I can't think how the current scheme would allow for
> making it balanced.

My suggestion was to build a new decision-tree every time a new item
was added, like now, with the only difference of using lots of small
code pieces to implement it instead of one big one.  I wasn't
suggesting updating the code-tree, like you would update a search
tree.

> I guess it would be doable if we stored the keys in an array not part of the
> code, as sorting it would not
> mean doing a lot of code modification, so no icache flushes unless we wanted
> to link a new trunk block
> in the tree and each trunk block could be a 15 entries decision tree.

I'm not sure I understand what you mean.  Could you give an example?

Thanks for the feedback!

Mark