Managed memory vs unmanaged memory

[William F. Kinsley]

My understanding is that when I re-compile a existing MFC application with
the /clr switch, that the code generated is managed(with some exceptions)
but that the data isn't, i.e. not garbage collected. I also noticed that
when replaced some of the existing MFC dialogs with managed winforms that
everything is still running in the same app domain.( No context change) So
my question is this, what are the performance differences in using managed
data vs. unmanaged data? Is there a difference in the way value types are
handled vs. reference types?

Thanks

Bill

[Carl Daniel [VC++ MVP]]

William F. Kinsley wrote:

My understanding is that when I re-compile a existing MFC application
with the /clr switch, that the code generated is managed(with some
exceptions) but that the data isn't, i.e. not garbage collected.
Correct.
I
also noticed that when replaced some of the existing MFC dialogs with
managed winforms that everything is still running in the same app
domain.( No context change) So my question is this, what are the
performance differences in using managed data vs. unmanaged data? Is
there a difference in the way value types are handled vs. reference
types?

Managed data may move at any time. This means that managed data needs to be
pinned before being accessed by native code. Pinning, of course, incurs
additional overhead that unmanaged memory does not see. When managed data
is accessed by managed code, no pinning is necessary since the CLR can track
(and adjust) all references to the managed memory if it should move.

Value types on the managed heap are really no different, but value types as
local variables are quite different - they're basically the same as native
types as local variables. They are allocated directly on the stack,
embedded directly into other value types, etc.

There is a context change of sorts when moving from managed to unmanaged
code (and vice-versa) because of coordination with the GC. For example, the
GC can freeze a thread running managed code at nearly any point in it's
execution. If a thread is running native code, however, the GC will not
freeze that thread until it returns to managed code.

-cd

[William F. Kinsley]

Thank for your help, however I have some follow up questions,
1) Ok, I understand that managed pointers copied to an unmanaged pointer
that it must be pinned, but since I am working in MC++ and I'll have both
managed and on managed pointers, how can I tell the differences? For
example, in this code sample below:
a) Both integers are created on the stack (there is only one stack,
right? there is not a managed stack and unmanaged stack?
b) fFArray and dlg are on the managed heap? These do not need to be
pined, right?
c) pObj is a pointer on the stack and it points to an managed object and
needs to be pinned, right?
System::Int32 sysInt32;
int nativeInt;
System::Object __pin *pObj;

#pragma push_macro("new ")
#undef new
float fFArray2 __gc[] = new float __gc[5];
MFCTestApp::GCA boutDlg *dlg;
dlg = __gc new MFCTestApp::GCA boutDlg ();
pObj = dlg;
#pragma pop_macro("new" )

dlg->ShowDialog() ;
pObj = 0;
delete dlg;
dlg = 0;
2) An in your last paragraph, are you refering to boxing?
Again, thank you for your help,
Bill

"Carl Daniel [VC++ MVP]" <cp************ *************** **@mvps.org.nos pam>
wrote in message news:OQ******** ******@TK2MSFTN GP15.phx.gbl...

William F. Kinsley wrote:

My understanding is that when I re-compile a existing MFC application
with the /clr switch, that the code generated is managed(with some
exceptions) but that the data isn't, i.e. not garbage collected.
Correct.

I
also noticed that when replaced some of the existing MFC dialogs with
managed winforms that everything is still running in the same app
domain.( No context change) So my question is this, what are the
performance differences in using managed data vs. unmanaged data? Is
there a difference in the way value types are handled vs. reference
types?

Managed data may move at any time. This means that managed data needs to

be pinned before being accessed by native code. Pinning, of course, incurs
additional overhead that unmanaged memory does not see. When managed data
is accessed by managed code, no pinning is necessary since the CLR can track (and adjust) all references to the managed memory if it should move.

Value types on the managed heap are really no different, but value types as local variables are quite different - they're basically the same as native
types as local variables. They are allocated directly on the stack,
embedded directly into other value types, etc.

There is a context change of sorts when moving from managed to unmanaged
code (and vice-versa) because of coordination with the GC. For example, the GC can freeze a thread running managed code at nearly any point in it's
execution. If a thread is running native code, however, the GC will not
freeze that thread until it returns to managed code.

-cd

[Carl Daniel [VC++ MVP]]

William F. Kinsley wrote:

Thank for your help, however I have some follow up questions,
1) Ok, I understand that managed pointers copied to an unmanaged
pointer that it must be pinned, but since I am working in MC++ and
I'll have both managed and on managed pointers, how can I tell the
differences? For example, in this code sample below:
In Managed Extensions for C++ it's very hard to tell sometimes. A simple
T* might be a native pointer, managed reference, or interior pointer and you
need to examine the context where it's declared to figure out which. In
VC++ 2005 the new C++/CLI bindings separate these concepts entirely: T* is
a native pointer, T& is a native reference, T^ is a managed "handle", T% is
a tracking reference, interior_ptr<T> is an interior pointer, pin_ptr<T> is
a pinned pointer.
a) Both integers are created on the stack (there is only one stack,
right? there is not a managed stack and unmanaged stack?
Yes, both on stack. Yes, only one stack, but the organization of the
managed portion of the stack may be different from that of the native stack
(in regard to parameter passing, local variable allocations, stack frame
setup, etc).
b) fFArray and dlg are on the managed heap? These do not need to be
pined, right?
Yes, both on managed heap. These need to be pinned iff they are passed to
native code. Items accessed from managed code never need to be pinned.
c) pObj is a pointer on the stack and it points to an managed
object and needs to be pinned, right?
pObj is a value type (pointer) and lives on the stack. It needs to be
pinned if it's passed to native code. It's really no different from dlg in
terms of needing to be pinned or not.

[snipped code]
2) An in your last paragraph, are you refering to boxing?

No. Boxing is the process of placing a value type on the managed heap.
This is relevant to the second-to-last paragraph that I wrote. Value types
live on the stack or directly embedded in other objects. Boxed value types
live on the managed heap and are referenced like any reference type.

In the last paragraph I'm referring to context-switch work that goes on
whenever a thread enters or leaves native code. Every time managed code
calls native code, the compiler has to generate code more or less equivalent
to:

prepare_to_exit _clr()
marshall_params _to_native_stac k()
call_native_fun ction()
marshall_return _to_managed_sta ck()
reenter_clr()

It doesn't really generate calls for all those things, but they all occur.
It's not exactly a context switch, but it's a lot more than simply calling a
function.

-cd

[William F. Kinsley]

Thank you, I think I now understand this a little better now.

Bill
"Carl Daniel [VC++ MVP]" <cp************ *************** **@mvps.org.nos pam>
wrote in message news:Oo******** ******@TK2MSFTN GP09.phx.gbl...

William F. Kinsley wrote:

Thank for your help, however I have some follow up questions,
1) Ok, I understand that managed pointers copied to an unmanaged
pointer that it must be pinned, but since I am working in MC++ and
I'll have both managed and on managed pointers, how can I tell the
differences? For example, in this code sample below:
In Managed Extensions for C++ it's very hard to tell sometimes. A simple
T* might be a native pointer, managed reference, or interior pointer and

you need to examine the context where it's declared to figure out which. In
VC++ 2005 the new C++/CLI bindings separate these concepts entirely: T* is a native pointer, T& is a native reference, T^ is a managed "handle", T% is a tracking reference, interior_ptr<T> is an interior pointer, pin_ptr<T> is a pinned pointer.

a) Both integers are created on the stack (there is only one stack,
right? there is not a managed stack and unmanaged stack?
Yes, both on stack. Yes, only one stack, but the organization of the
managed portion of the stack may be different from that of the native

stack (in regard to parameter passing, local variable allocations, stack frame
setup, etc).

b) fFArray and dlg are on the managed heap? These do not need to be
pined, right?
Yes, both on managed heap. These need to be pinned iff they are passed to
native code. Items accessed from managed code never need to be pinned.

c) pObj is a pointer on the stack and it points to an managed
object and needs to be pinned, right?

pObj is a value type (pointer) and lives on the stack. It needs to be
pinned if it's passed to native code. It's really no different from dlg

in terms of needing to be pinned or not.

[snipped code]

2) An in your last paragraph, are you refering to boxing?
No. Boxing is the process of placing a value type on the managed heap.
This is relevant to the second-to-last paragraph that I wrote. Value

types live on the stack or directly embedded in other objects. Boxed value types live on the managed heap and are referenced like any reference type.

In the last paragraph I'm referring to context-switch work that goes on
whenever a thread enters or leaves native code. Every time managed code
calls native code, the compiler has to generate code more or less equivalent to:

prepare_to_exit _clr()
marshall_params _to_native_stac k()
call_native_fun ction()
marshall_return _to_managed_sta ck()
reenter_clr()

It doesn't really generate calls for all those things, but they all occur.
It's not exactly a context switch, but it's a lot more than simply calling a function.

-cd