Why is the method table set and reset every time instead of just once?

[AnsisMalins]

As I step through the code, I notice that V8SplitProxyManaged.MethodTable starts out null and is then set to the same value one or more times as I descend down the stack, once for every Invoke or InvokeNoThrow. And when the stack unwinds, it is set back to null. What is the point? There is no other code that I can find that would touch that field, so why not just set it once on startup?

[ClearScriptLib]

Hello @AnsisMalins,

why not just set it once on startup?

The address of the method table must be stored per-thread to accommodate .NET Framework, which supports application domains. In that environment, each entry in the table actually points at a thunk that enters the appropriate application domain before invoking the target managed code.

Each domain in a multi-domain application can load its own copy of ClearScript and construct its own method table. Because a managed thread can never switch application domains, it would be possible to assign the method table once per thread, but, at the time, we weren't sure that was going to remain the case in future .NET Framework versions, so we chose the set-reset pattern you see today – in anticipation of direct cross-domain calls – a capability that never materialized.

BTW, this isn't just theory. Before version 7.0, ClearScript's V8 proxy – the interface between managed and native code – was implemented in C++/CLI and could talk to both sides trivially, with the compiler handling the multi-domain problem. Later, when the proxy was split into managed and native portions for cross-platform support (hence SplitProxy 😁), a pre-release tester actually ran into this issue.

Cheers!

[AnsisMalins]

Do you have any reason to keep that code around, or did you just not get around to getting rid of it? Would you accept a pull request that gets rid of it?

[ClearScriptLib]

Do you have any reason to keep that code around, or did you just not get around to getting rid of it?

We haven't dropped support for .NET Framework. In the meantime, we've tried to reduce performance impact by (a) foregoing method table assignment when calling native code that never calls back, and (b) bypassing method table reset to the same address.