[Mono-dev] Supporting ICastable on Mono Windows x64.

[Johan Lorensson]

Hi,

Below is a proposed solution to implement support of CoreCLR ICastable
feature on Mono Windows x64.

*Why:*

ICastable is supported by CoreCLR and used by MCG (Microsoft interop
codegen tooling for WinRT API's) in order to call WinRT API's from managed
code on Windows platforms. MCG consumes winmd files + a closure of WinRT
API used by an application generating managed interop code. Supporting
ICastable is a prerequisite in order to support MCG on Mono Windows x64.

The requirements on the ICastable feature is described in the interface:

https://github.com/dotnet/coreclr/blob/68f72dd2587c3365a9fe74d1991f93
612c3bc62a/src/mscorlib/src/System/Runtime/CompilerServices/ICastable.cs

There is also a test case that will be used to validate Mono's
implementation of ICastable:

https://github.com/dotnet/coreclr/blob/84aab5f59d023849b9ccdc290e698e
4a61ac75a2/tests/src/Interop/ICastable/Castable.cs

The ICastable implementation + additional Mono extensions will also be used
to run a couple of MCG->WinRT samples testing MCG's usage of Mono's
ICastable implementation.

All should work on Windows x64 JIT + full AOT.

*How:*

ICastable is a specific feature with several restrictions and constraints.
The purpose is to dynamically, at runtime, add interfaces and
implementation to a type that is not part of the types original metadata.
The added interfaces are then implemented by a complete different unrelated
type returned by implementation of ICastable interface. That put some
specific requirements on both the runtime but also on the implementation of
the class implementing the ICastable interface and its dispatch targets.
Due to this, the feature should be considered "Private" limiting it's use
and support to specific use cases. The main initial target is MCG stubs and
interopability with WinRT API's on Windows platforms.

*Extending Mono Runtime:*

Looking into the current Mono source there is currently a feature that has
similar characteristics and behavior as ICastable, transparent proxy
support used by remoting. The plan is to use that as inspiration but not
depending on current implementation (should not need to include remoting
support to work). The underlying mechanism is still similar, dynamically
extend an objects vtable if an objects gets casted to an interface
indirectly supported by the underlying implementation of ICastable (or
IRemotingTypeInfo.CanCastTo in remoting use case). The idea is to
generalize and share the code already doing this logic in remoting making
sure we only include one implementation of key features like rebuilding the
vtable (currently done in mono_class_proxy_vtable). ICastable
implementation will also include a cache similar to the one used in the
remoting use case (see mono_upgrade_remote_class for details).

All code related to the ICastable feature will be guarded by a defined,
FEATURE_ICASTABLE, so all platforms not needing this support (currently
only needed on WinRT platforms), won't be affected by this change.

*Extending Mono BCL:*

The ICastable implementation + helper class can be included from CoreCLR
into Mono's mscorlib with a small adjustment to the helper class:

https://github.com/dotnet/coreclr/blob/68f72dd2587c3365a9fe74d1991f93
612c3bc62a/src/mscorlib/src/System/Runtime/CompilerServices/ICastable.cs

Part of supporting ICastable includes adding the above assembly and classes
to Mono's BCL. It should build under net_4_x and winAOT profiles.

*Examples of things that needs to be done to support ICastable:*


   - Extend MonoVTable with a field indicating support for ICastable
   (optimization for fast lookups and checks). Since this field is checked
   both by C code and generated code (handle_isinst, handle_castclass) it
   needs to be addressable. Field will also be used to include more meta
   information when an object implements ICastable and has been casted to
   different interfaces (needed by both caching and vtable rebuild).
   - Extend mono_object_handle_isinst_mbyref to have fallback for objects
   supporting ICastable.
   - Extend handle_isinst and handle_castclass to have fallback for objects
   supporting ICastable.
   - Extend objects vtable with new interfaces implemented by a different
   type indicated by ICastable::IsInstanceOfInterface. Similar to how
   mono_upgrade_remote_class works for remote objects.
   - Add support to mono_vcall_trampoline to resolve method implementation
   for ICastable objects when not directly implemented by type. Implementing
   type for method is returned by ICastable::GetImplType.
   - Cache dynamically generated vtables based on object class + additional
   supported interface(s).
   - Add support for CoreCLR ICastable interface and support class in
   Mono's mscorlib (net_4_x, winAOT profiles).

I have implemented a POC using the above approach and it solve the use
case, getting pass on all tests in CoreCLR ICastable test suite and working
with MCG stub samples, so above suggestion seems at least to be a way
moving forward implementing support for ICastable on Mono Windows x64.

Comments, thoughts and ideas are much appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20170516/c14b35d2/attachment-0001.html>