Статический анализ вызовов виртуального общего метода

Question

Xamarin - это система, которая полностью компилирует код .NET (AOT) для платформ, которые запрещают выполнение данных и поэтому не могут иметь JIT. Этот вопрос касается не Xamarin, а утверждения о том, что делает его документация. Он заявляет here:

Generic поддержка виртуальных методов ограничена, это не представляется возможным статически определить, какой метод будет вызываться при любых обстоятельствах, так что компилятор может оставить несколько из них.

Я мог ошибаться, но они, похоже, подразумевают широкое утверждение о том, что возможно здесь, посредством статического анализа, а не только того, что они выбрали для реализации в своем собственном программном обеспечении.

Как указал Ханс Пассант, пример, который они дают, фактически не демонстрирует проблему, о которой они имеют в виду, поэтому я исключил ее.

Таким образом, помимо этих, безусловно, неразрешимых особых случаев:

• Отражение;

• динамически сгенерированный код (в любом случае это незаконно);

• патологические циклические ссылки в аргументах типа с использованием типов значений; и

• зарубежные сборки;

Что могло бы сделать компилятор AOT неспособным обрабатывать виртуальный общий случай метода?

Answer 1

Этот пример - только borken и не демонстрирует проблему вообще. Неявные виртуальные методы заключаются в том, что компилятор не может достоверно определить, с каких сайтов вызовов можно вызвать метод. Что является проблемой для общего метода, поскольку компилятор должен создать несколько его версий.

Одна версии необходима для обработки любого ссылочного типа, в частности, покрытое замечанием «Это вообще безопасно использовать общий виртуальный метод с ссылочными типами, как Object или String, учитывая компилятор всегда скомпилировать версию, которая может обрабатывать тогда". Или, другими словами, он, вероятно, просто слепо порождает эту.

Нарушениями являются версии, где T - тип значения. Один конкретный конкретный метод должен быть скомпилирован для каждого отдельного типа значений. Поскольку компилятор не может догадаться на сайте вызова, он также не может видеть, какие типы значений он должен создать для этого метода. Слепое их создание нецелесообразно из-за структурных типов и методов с несколькими параметрами типа.

Answer 2

Я принципиально согласен с вашим анализом.

Xamarin и аналогичные инструменты могут идти об этом в обратном порядке, так сказать, путем включения всех возможных сочетаний типа экземпляра и подписи виртуального метода, а затем продолжить удаление только тех, которые, по-видимому, не нужны.

Возможно, они попытались это сделать и обнаружили, что полученный код, как правило, становится довольно большим/медленным для сложных иерархий объектов.