4

I'm currently looking into using C++/CLI to bridge the gap between managed C# and native, unmanaged C++ code. One particular issue I'm looking to resolve, is the conversion of data types that are different in C# and C++.

While reading up on the use of such a bridging approach and the performance implications involved, I wondered how Garbage Collection would work. Specifically, how the Garbage Collector would handle cleanup of objects created on either side, if they are referenced / destroyed on the 'other side'.

So far, I've read various articles and forum questions on StackOverflow and MSDN, which has lead me to believe that the Garbage Collector should work across both types of code when running in the same process - i.e if an object was created in C# and passed to the C++/CLI bridge, it would not be collected until the references on both sides were no longer in use.

My question in this case, breaks down into three parts:

  1. Am I right in concluding that the Garbage Collector works across both portions of code (C# and C++/CLI) when running in the same process?
  2. In relation to 1: how does it work in such a circumstance (specifically in terms of cleaning up objects referenced by both code bases).
  3. Are there any suggestions on how to monitor the activity of the Garbage Collector - i.e. writing tests to check when Garbage Collection occurs; or a program that monitors the Garbage Collector itself.

I already have somewhat of an understanding of how the Garbage Collector works in general, so my questions here are specific to the following scenario:

Components

  • Assembly A - (written in C#)
  • Assembly B - (written in C++/CLI)

Program Execution

  1. Object O is created in Assembly A.
  2. Object O is passed into a function inside Assembly B.
  3. Reference to object O in Assembly A is released.
  4. Assembly B holds onto reference to object O.
  5. Execution ends (i.e. via program exit).
  6. Assembly B releases reference to object O.

Thanks in advance for any thoughts on this question. Let me know if further information is needed or if something is not clear enough.

EDIT

As per request, I have written a rough example of the scenario I'm trying to describe. The C# and C++/CLI code can be found on PasteBin.

Community
  • 1
  • 1
Samuel Slade
  • 8,405
  • 6
  • 33
  • 55
  • You should clean up any references in the C++ code. You should do the same with C# if its applicable. Perhaps if you provide an code example your question would be clear. – Security Hound Jan 06 '12 at 12:47

2 Answers2

4

When the code is actually running, none of it will be C# or C++/CLI. All of it will be IL from the C# and C++/CLI and machine code from the native code you're interoperating with.

Hence you could re-write part of your question as:

  • Assembly A - (IL and we don't know what it was written in)
  • Assembly B - (IL and we don't know what it was written in)

Of the managed objects, all of them will be garbage collected as per the same rules, unless you use a mechanism to prevent it (GC.KeepAlive). All of them could be moved in memory unless you pin them (because you're passing addresses to unmanaged code.

.NET Profiler will give you some information on garbage collection, as will the collection counts in performance monitor.

Jon Hanna
  • 110,372
  • 10
  • 146
  • 251
  • +1 The garbage collector has no notion of C# or C++/CLI - at this level everything is CIL. – MattDavey Jan 06 '12 at 14:28
  • Not really. At this level it is all machine code, whether it was produced by the jitter or the C++ code generator. – Hans Passant Jan 06 '12 at 14:37
  • @HansPassant At which "this level"? At the level it runs, it's all machine code of course, but that which at another level is IL will be machine code that cooperates with the GC, and the rest will not. I think Matt's choice of which level is "this level" is more pertinent. – Jon Hanna Jan 06 '12 at 14:43
1

Am I right in concluding that the Garbage Collector works across both portions of code (C# and C++/CLI) when running in the same process?

Yes, a single garbage collector works inside one process for both (C# and Managed C++) . If inside one process there is code that is running under different CLR versions then there will be different instance of GC for each CLR version

In relation to 1: how does it work in such a circumstance (specifically in terms of cleaning up objects referenced by both code bases).

I think for GC it doesn't matter if the code is managed C# or C++/CLI (Note that GC will only manage C# and Managed C++ code not native C++). It will work in it's own way without considering what type of code underlying is. Regarding freeing memory, GC will do that whenever an object can no longer be referenced. So as long as there is something referring to a variable it won't be collected regardless of assembly. For native C++ code you will have to manually free every dynamically allocated memory

Are there any suggestions on how to monitor the activity of the Garbage Collector - i.e. writing tests to check when Garbage Collection occurs; or a program that monitors the Garbage Collector itself.

You can use tools like .Net Profiler for monitoring. Also take a look at Garbage Collection Notifications

Daniel
  • 30,896
  • 18
  • 85
  • 139
Haris Hasan
  • 29,856
  • 10
  • 92
  • 122