You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So due to special method names, our current implementation relies on method name lookups which is bad.
An alternative to this would be to create a method, say, RunVirtualMethod which would take in an instance (that must have a vtable) and MethodInfo* that is looked at for its SLOT and declaring type + params/ret, and will forward to RunMethod... of some variant AFTER the correct method is deduced via slot and instance vtable. The way this will have to be done is by class resolution + interface/base type analysis--
A base type must be the first vtable_count slots of the target instance's vtable
Interfaces are arranged in the order they are declared in after this
Target slot should be found by taking initial offset (0 for base types, or non-zero for any interface, must be deduced) and adding our input slot to that result.
Target slot should be looked up in the target vtable ex: target_vtable[target_slot] and the corresponding method pointer should be extracted, then passed into any of the remaining invokes.
This functionality probably should encompass several methods (forwards to multiple RM calls) and probably also support a "conversion" call without invoke (to resolve a given input slot on a given instance to a method pointer)
Some corners can be cut that can be reasonably inferred, but it will be tricky to cut out some others (ex, vtable distributions can't be encoded in an incredibly sane way AOT, deduction almost certainly has to take place on runtime)
The text was updated successfully, but these errors were encountered:
So due to special method names, our current implementation relies on method name lookups which is bad.
An alternative to this would be to create a method, say,
RunVirtualMethod
which would take in an instance (that must have a vtable) and MethodInfo* that is looked at for its SLOT and declaring type + params/ret, and will forward toRunMethod...
of some variant AFTER the correct method is deduced via slot and instance vtable. The way this will have to be done is by class resolution + interface/base type analysis--vtable_count
slots of the target instance's vtabletarget_vtable[target_slot]
and the corresponding method pointer should be extracted, then passed into any of the remaining invokes.This functionality probably should encompass several methods (forwards to multiple RM calls) and probably also support a "conversion" call without invoke (to resolve a given input slot on a given instance to a method pointer)
Some corners can be cut that can be reasonably inferred, but it will be tricky to cut out some others (ex, vtable distributions can't be encoded in an incredibly sane way AOT, deduction almost certainly has to take place on runtime)
The text was updated successfully, but these errors were encountered: