Джефри Рихтер, CLR via C# > Алгоритм сборки мусора
Когда я говорил про таблицу методов, я имел ввиду следующее:
Генерация машинного кода JIТ-компилятором сопровождается созданием внутренней таблицы. Логически каждая ее строка указывает диапазон смещений байтов машинных кодов процессора для этого метода, а также для каждого диапазона — набор адресов памяти и регистры процессора, содержащие корни.
When a method is JIT compiled, the JIT compiler creates a table indicating the method’s roots
The GC uses this table
The table looks something like this…
Джефри Рихтер, CLR via C# > Мониторинг и контроль времени жизни объектов
Для каждого домена приложения CLR поддерживает таблицу GС-дескрипторов ( GC handle table), с помощью которой приложение отслеживает время жизни объекта или позволяет управлять им вручную. В момент создания домена приложения таблица пуста. Каждый элемент таблицы состоит из указателя на объект в управляемой куче и флага, задающего способ мониторинга или контроля объекта.
А вы говорите видимо как раз про эту таблицу GC-дескрипторов (GC handle table), с помощью которой можно управлять объектами им вручную (как в вашем примере, проставить с помощью GC.KeepAlive флаг о запрете на перемещение, в случае сценария взаимодействия с неуправляемым кодом).
Прочитал статью более 5 раз, но до сих пор осталось несколько вопросов:
Объект может быть удален до того, как отработает метод, который этот объект вызывает
Я правильно понимаю, что в данном случае нет ничего необычного — глядя в таблицу методов (с рутами), GC видит, что в дальнейшем на переменную никто не ссылается и просто принимает решение о том, что её можно удалить?
Это работает потому, что методы экземпляров ничем не отличаются от статических методов, кроме того, что в нем передается скрытый параметр — ссылка this, которая ничем не лучше остальных параметров метода. Ну и еще небольшие отличия есть с точки зрения CIL (методы экземпляров всегда вызываются с помощью callvirt, даже те, которые не помечены как виртуальные, когда как для статических методов используется простой call)
Не могли бы вы поподробнее описать, что здесь имелось в виду и как на самом деле на нижнем уровне происходит вызов (через call или callvirt, по какому адресу осуществляется вызов, какое значение имеет указатель this и как влияет на вызов удаление экземпляра сборщиком мусора).
2-да года назад ставил убунту на свой новый комп. Да почти все заработало. Кроме сетевой карточки — не те дрова установились. Пакеты терялись инет работал очень медленно. Начал гуглить — да решил проблему. Но факт остается фактом — Только трастовое железо аля мак — или гугл + мозги или знакомый линуксоид. Глюкис.
Когда я говорил про таблицу методов, я имел ввиду следующее:
По теме: download.microsoft.com/download/e/2/1/e216b4ce-1417-41af-863d-ec15f2d31b59/DEV490.ppt (Презентация .NET Framework:CLR – Under The Hood, Jeffrey Richter)
30 слайд:
Джефри Рихтер, CLR via C# > Мониторинг и контроль времени жизни объектов
А вы говорите видимо как раз про эту таблицу GC-дескрипторов (GC handle table), с помощью которой можно управлять объектами им вручную (как в вашем примере, проставить с помощью GC.KeepAlive флаг о запрете на перемещение, в случае сценария взаимодействия с неуправляемым кодом).
Я правильно понимаю, что в данном случае нет ничего необычного — глядя в таблицу методов (с рутами), GC видит, что в дальнейшем на переменную никто не ссылается и просто принимает решение о том, что её можно удалить?
Не могли бы вы поподробнее описать, что здесь имелось в виду и как на самом деле на нижнем уровне происходит вызов (через call или callvirt, по какому адресу осуществляется вызов, какое значение имеет указатель this и как влияет на вызов удаление экземпляра сборщиком мусора).
Я лишь в том плане что при желании можно и в 1с без особых велосипедов писать )
Конечно без некоторого богатства других сред разработки
infostart.ru/public/119601/ — JSON под 1с
infostart.ru/public/142730/ — rabbitmq — хотя лучше свою обертку написать