| Цитата | | А там и так его нет. Взаимодействие происходит в рамках одного языка - IL. |
Ну вот о том и речь, если бы взаимодействие происходило в пределах IL, то если в сборке native код, то взаимодействия бы не было.
Но взаимодействие просиходит из-за метаданных. Поэтому межъязвковое взаимодействие остается.
| Цитата | я не видел ни одной .NET проги под юникс. А может кто-нибудь видел такие?
|
Я видел.
DotGNU project
Mono project
вполне рабочие проекты .Net под Linux, и это только те, о которых я слышал.
ссылка на скриншоты DotGNU :
http://www.gnu.org/projects/dotgnu/screenshots.html
| Цитата | | IMHO, всё предельно просто |
Оказалось, что это не так.
На самом деле JIT не сканирует код. В начале все (почти все) указатели в таблицах методов (или как они называются) указывают на точку входа в JIT, который компилирует код и изменяет указатель в таблице, чтобы он указывал на скомпилированный код.
Т.е. в таблицах метаданных, в которых находится и сам IL код, указатель для каждой ячейки таблицы с IL кодом указывает на точку входа в JIT. И когда кусок кода IL среда хочет скомпилировать, она просто дергает за этот указатель, и для этого куска кода срабатывает JIT. Поэтому, если в сборках(точнее в ее таблицах)содержится не IL код, а native, то адрес указателя для определенного куска native кода уже указывает не на точку входа в JIT, а сразу на себя, потому что это уже готовый скомпилированный код, и тем самым мы не вызываем JIT для компиляции этого куска кода, а зразу исполняем его. Правильно?
Везде пишут, что JIT сканирует код перед тем как его начать компилировать и определяет какие сборки необходимо еще загрузить. Но ведь такого быть не может. Ведь он компилирует только IL код, а IL код содержит только инструкции, поэтому даже просканировав IL код, нельзя определить какие типы нам понадобятся и какие сборки для этого надо загрузить. Это определяет CLR. |
