Сборка мусора между объектами C # и C ++ / CLI - PullRequest
Новая
       19

Сборка мусора между объектами C # и C ++ / CLI

3 голосов
/ 06 января 2012

В настоящее время я изучаю использование C ++ / CLI для преодоления разрыва между управляемым C # и собственным неуправляемым кодом C ++.Одна конкретная проблема, которую я хочу решить, - это преобразование типов данных, которые отличаются в C # и C ++.

Читая об использовании такого мостового подхода и связанных с этим последствиях для производительности, я удивился, какСборка мусора будет работать.В частности, как сборщик мусора будет обрабатывать объекты, созданные с обеих сторон, если на них ссылаются / уничтожают «с другой стороны».

До сих пор я читал различные статьи и вопросы на форуме по StackOverflow и MSDN , что привело меня к мысли, что сборщик мусора должен работать с обоими типами кода при работе в одном и том же процессе - т.е. если объект был создан в C # и передан вМост C ++ / CLI, он не будет собираться до тех пор, пока ссылки на обе стороны больше не будут использоваться.

Мой вопрос в этом случае разбивается на три части:

  1. AmЯ прав в заключении, что сборщик мусора работает в обеих частях кода (C # и C ++ / CLI) при запуске в одном и том же процессе?
  2. По отношению к 1: как он работает в таких обстоятельствах (особенно вусловия очистки объектов, на которые ссылаются обе базы кода).
  3. Есть ли какие-либо предложения о том, как контролировать активностьСборщик мусора - т.е. написание тестов для проверки, когда происходит сборка мусора;или программа, которая следит за сборщиком мусора.

У меня уже есть понимание того, как работает сборщик мусора в целом, поэтому мои вопросы здесь относятся к следующему сценарию:

Компоненты

  • Сборка A - (написано на C #)
  • Сборка B - (написано на C ++ / CLI)

Выполнение программы

  1. Объект O создан в Сборка A .
  2. Объект O передается в функцию внутри Сборка B .
  3. Ссылка на объект O в Сборка A освобождается.
  4. Сборка B удерживает ссылку на объект O.
  5. Выполнение заканчивается (т. Е. При выходе из программы).
  6. Сборка B освобождает ссылку наobject O.

Заранее спасибо за любые мысли по этому вопросу.Дайте мне знать, если необходима дополнительная информация или что-то не совсем понятно.

РЕДАКТИРОВАТЬ

В соответствии с запросом, я написал пример грубого сценария I 'Я пытаюсь описать.Код C # и C ++ / CLI можно найти в PasteBin.

Ответы [ 2 ]

4 голосов
/ 06 января 2012

Когда код фактически выполняется, ни один из них не будет C # или C ++ / CLI.Все это будет IL из C # и C ++ / CLI и машинный код из нативного кода, с которым вы взаимодействуете.

Следовательно, вы можете переписать часть своего вопроса как:

  • Сборка A - (IL, и мы не знаем, что было написано)
  • Сборка B - (IL, и мы не знаем, что было написано)

Из управляемых объектов все они будут собираться мусором по одним и тем же правилам, если только вы не используете механизм для предотвращения этого (GC.KeepAlive).Все они могут быть перемещены в память, если вы не закрепите их (потому что вы передаете адреса неуправляемому коду.

.NET Profiler даст вам некоторую информацию о сборке мусора, так же как и сборщик подсчитывает в мониторе производительности.

1 голос
/ 06 января 2012

Прав ли я, заключая, что сборщик мусора работает на обоих части кода (C # и C ++ / CLI) при запуске в одном и том же процессе?

Да, один сборщик мусора работает внутри одного процесса для обоих (C # и Managed C ++). Если внутри одного процесса есть код, который выполняется под разными версиями CLR, то для каждой версии CLR будет свой экземпляр GC

По отношению к 1: как это работает в таких обстоятельствах (особенно с точки зрения очистки объектов, на которые ссылаются обе базы кода).

Я думаю, что для GC не имеет значения, является ли код управляемым C # или C ++ / CLI (обратите внимание, что GC будет управлять только C # и кодом Managed C ++, а не собственным C ++). Он будет работать по-своему, не учитывая, какой тип кода лежит в основе. Что касается освобождения памяти, GC будет делать это всякий раз, когда на объект больше нельзя ссылаться. Таким образом, пока что-то ссылается на переменную, оно не будет собираться независимо от сборки. Для нативного кода C ++ вам придется вручную освобождать каждую динамически выделенную память

Есть ли какие-либо предложения по мониторингу активности мусора Collector - то есть написание тестов для проверки, когда происходит сборка мусора; или же программа, которая контролирует сборщик мусора.

Вы можете использовать такие инструменты, как .Net Profiler для мониторинга. Также обратите внимание на Уведомления о сборке мусора

...