GC and pinned pointers

[_BNC]

Another thread mentioned non-Pinned pointers as a possible reason for an
Interop bug. I'd like to find out more about how this comes about. I
presume that the Garbage Collector makes a sweep, decides to realloc
memory that is not pinned, and that the unmanaged code's pointer becomes
invalid.

How often does the GC run, given a reasonably large app running on
a P4 300ghz with over 1 gig ram? I would have thought that it did not
need to run often at all.

Is there any other possible cause for the unpinned pointer problems?

 

[Joakim Karlsson]

Another thread mentioned non-Pinned pointers as a possible reason for an
Interop bug. I'd like to find out more about how this comes about. I
presume that the Garbage Collector makes a sweep, decides to realloc
memory that is not pinned, and that the unmanaged code's pointer becomes
invalid.

IIRC unmanaged code can only reference pinned objects, the GC is not
allowed to move pinned objects, so the unmanaged pointer does not become
invalid.

How often does the GC run, given a reasonably large app running on
a P4 300ghz with over 1 gig ram? I would have thought that it did not
need to run often at all.

A GC is performed each time your application wants to allocate an object
and generation 0's threshold is reached (something like 256K i think).
So, how often a GC is performed depends on how your application is behaving.

Regards,
Joakim

 

[Willy Denoyette [MVP]]

The number of GC run's depend highly on your usage pattern NOT the systems
CPU performance, if you allocate very frequently, the GC will run very
frequently .
If you don't allocate at all, the GC will not run at all(unless the system
runs low on memory).
You should not care about the number of GC runs, you have to pin the
pointers you pass to unmanaged code that's all.

Willy.

 

[Derrick Coetzee [MSFT]]

I'm still trying to get a handle on the subtleties of the
managed-to-unmanaged bridge. Much of this seems counterintuitive to me.
For instance, the MSDN code that uses a similar method:

http://msdn.microsoft.com/library/d.../vcgrfmanagedwrappersaroundunmanagedtypes.asp

does not __pin the pointer to the unmanaged struct (see constructor:
"city = new CITY;"). I'm trying to figure out why that pointer does not
need to be pinned.

I can try to help explain this part. The garbage collector ignores
unmanaged objects altogether; it will not move them, it will not free
them, and they cannot be pinned. If you define a managed (__gc) C++
class that contains pointers to unmanaged objects, the garbage collector
simply ignores these pointers. It is the job of that class's destructor
to deallocate the objects properly, and GC invokes this destructor at
the appropriate time. More generally, *managed code* is able to deal
with and contain *unmanaged objects* without much of a problem.

It is going in the other direction that pinning comes into play - if you
use *unmanaged code* to deal with pointers to *managed objects*. In this
case, GC does know about the object, and what it doesn't know about are
the unmanaged pointers to it. This prevents it from updating these
pointers after moving the object. Also, if only unmanaged pointers to an
object exist (which it doesn't know about) it will assume the object can
be freed. Pinning prevents this as well. Unfortunately, excessive
pinning also inhibits the efficiency of the collector, because it's
harder to find space to allocate in a highly fragmented memory pool.

 

[_BNC]

The number of GC run's depend highly on your usage pattern NOT the systems
CPU performance, if you allocate very frequently, the GC will run very
frequently .
If you don't allocate at all, the GC will not run at all(unless the system
runs low on memory).
You should not care about the number of GC runs, you have to pin the
pointers you pass to unmanaged code that's all.

Willy.

Thanks for your reply, Willy. I'm not being stubborn about pinning
pointers...I'm trying to figure out if I missed one somewhere. Or maybe
it's another problem entirely, I don't know. I'm not doing that many
memory allocs. I initially didn't figure that the GC would be the
culprit, but since problems turn up only when the program is stressed, it
would seem a likeley suspect. The smaller test models that I've worked up
run fine, of course.

I'm still trying to get a handle on the subtleties of the
managed-to-unmanaged bridge. Much of this seems counterintuitive to me.
For instance, the MSDN code that uses a similar method:

http://msdn.microsoft.com/library/d.../vcgrfmanagedwrappersaroundunmanagedtypes.asp

does not __pin the pointer to the unmanaged struct (see constructor:
"city = new CITY;"). I'm trying to figure out why that pointer does not
need to be pinned.

I started my original model from code in a wrox book
"Visual C++.NET: a primer for C++ Developers" (Aravind Corera, etc,
ISBN 1861005962). which outlines the approach of using 'concentric'
classes layered around internal unmanaged code (Center = DLL, then
unmanaged C++ wrapper, then managed C++ wrapper, then C#). They
do not pin the pointer to the unmanaged C++ wrapper either.

I would have gone with PInvoke from the start, but the central DLL is such
a mess, with tons of obscure structs and defined data types, that it
seemed more logical to encapsulate the ugly stuff on the unmanaged side of
the fence.

I'm afraid that by the time I get a good handle on how the interim
layering works, Whidbey will have made it obsolete and my project will be
over. <g> (IOW, the real problem is a stupid typo somewhere)

_B

 

[_BNC]

I can try to help explain this part. The garbage collector ignores
unmanaged objects altogether; it will not move them, it will not free
them, and they cannot be pinned. If you define a managed (__gc) C++
class that contains pointers to unmanaged objects, the garbage collector
simply ignores these pointers. It is the job of that class's destructor
to deallocate the objects properly, and GC invokes this destructor at
the appropriate time. More generally, *managed code* is able to deal
with and contain *unmanaged objects* without much of a problem.

That makes sense. Still, it seems like the example code effectively
allocs the inner unmanaged struct and maintains that pointer to that
struct without having to be pinned. I could swear that I've seen
equivalent pointers pinned in some example code, but I guess this will
make sense after it sinks in.

Now I've got to look for another cause for my problems though, cause I'm
allocing a block of ram in an unmanaged module, and the only thing that
the managed code does is pass the pointer to it to another unmanaged
class. No allocs are done by the managed code, and my understanding
is that the pointer itself is safe, being a low-level item.

It is going in the other direction that pinning comes into play - if you
use *unmanaged code* to deal with pointers to *managed objects*. In this
case, GC does know about the object, and what it doesn't know about are
the unmanaged pointers to it. This prevents it from updating these
pointers after moving the object. Also, if only unmanaged pointers to an
object exist (which it doesn't know about) it will assume the object can
be freed. Pinning prevents this as well.

A lucid explanation, Derrick.

Unfortunately, excessive
pinning also inhibits the efficiency of the collector, because it's
harder to find space to allocate in a highly fragmented memory pool.

I've heard that pinned pointers can effectively slow down the managed
code by a factor of 25 (!) so I've been trying to avoid them.

_B

 

[Derrick Coetzee [MSFT]]

Still, it seems like the example code effectively

allocs the inner unmanaged struct and maintains that pointer to that
struct without having to be pinned.

That's true; in fact, there's no point in pinning a pointer to an unmanaged
object, because the GC doesn't know about these objects and won't move them,
and ignores the pointer. Such blocks of memory are outside its control, just
like a block allocated in an unmanaged program. They are, effectively,
already pinned.

I could swear that I've seen equivalent pointers pinned in some example

code [ . . . ]

This may have been a pointer to a managed object, or it might have been a
mistake. It might let you create pinned pointers to unmanaged objects,
although this is pointless, since they're already "pinned."

Now I've got to look for another cause for my problems though, cause I'm
allocing a block of ram in an unmanaged module, and the only thing that
the managed code does is pass the pointer to it to another unmanaged
class. No allocs are done by the managed code, and my understanding
is that the pointer itself is safe, being a low-level item.

The Framework shouldn't interfere with unmanaged-to-unmanaged interactions,
as a rule. It sounds like your application has some very subtle problems.
I'm not sure where to tell you to start, but if you can find an alternative
to interfacing managed and unmanaged code using a mixed-code DLL, this might
be the simplest way to go. For example, I once did something similar to this
where in the end I ended up driving the C module through a command-line
interface and input/output files. You may also try using PInvoke to call
directly from the managed to the unmanaged code. In C# this is done with the
DllImport attribute; see an example here:

http://msdn.microsoft.com/library/d...s/cscon/html/vctskcodeusingpinvokevisualc.asp

I've heard that pinned pointers can effectively slow down the managed
code by a factor of 25 (!) so I've been trying to avoid them.

The main problem is that it slows down garbage collection cycles and
allocations a great deal if you use many pinned pointers at once, and the
larger the objects you pin the worse the effect. Pinning some small things
here and there is relatively harmless.

 

[_BNC]

... there's no point in pinning a pointer to an unmanaged
object, because the GC doesn't know about these objects and won't move them,
and ignores the pointer. Such blocks of memory are outside its control, just
like a block allocated in an unmanaged program. They are, effectively,
already pinned.

That finally makes sense. I've assumed that if the alloc was done within
managed code, that it would be subject to garbage collection. It's one of
those subtleties that was not clear in the docs that I've read.

The Framework shouldn't interfere with unmanaged-to-unmanaged interactions,
as a rule. It sounds like your application has some very subtle problems.
I'm not sure where to tell you to start, but if you can find an alternative
to interfacing managed and unmanaged code using a mixed-code DLL, this might
be the simplest way to go.

I've heard of subtle bugs in .NET mixed mode in general. It's frustrating
in that so much work went into the mixed mode bridge, and it's difficult
to trace problems. Smaller, or unstressed models of the code work fine.
I thought maybe it was a task prioritization thing, as the access to the
mixed mode code occurs in a thread. Strangely enough, increasing the
thread priority makes the code *less* reliable. I'm not getting runtime
errors or exceptions--just wrong results. Very counterintuitive.

For example, I once did something similar to this
where in the end I ended up driving the C module through a command-line
interface and input/output files. You may also try using PInvoke to call
directly from the managed to the unmanaged code. In C# this is done with the
DllImport attribute; see an example here:

http://msdn.microsoft.com/library/d...s/cscon/html/vctskcodeusingpinvokevisualc.asp

Thanks for the link, Derrick. I first considered PInvoke, but thought
that mixed mode would be better for this app (see below). However, if the
..NET mixed-mode DLL has inherent problems, as in:

http://msdn.microsoft.com/library/d...stechart/html/vcconMixedDLLLoadingProblem.asp

...then I suppose I'll have to give up on it. Unfortunately, the inner C
DLL is very messy, with lots of typedefs and structs that would be tough
to marshal via PInvoke. The fallback plan may be to encapsulate the C DLL
in an unmanaged C++.NET class to simplify the interface, and use PInvoke
to access that.

I've essentially done the encapsulation part already in the course of
writing the mixed-mode DLL, so I suppose I could start from there and
just PInvoke the encapsulating class.

I've also written a completely unmanaged version of the code which works
fine under run-time stress. In other words, I've got lots of clues, all

Derrick Coetzee, Microsoft Speech Server developer

Thanks for your perspective, Derrick. My understanding of the
managed-to-unmanaged transition is improving.

Re MS Speech server: I know you're probably more involved with the
ASP-related side of the MS Speech SDK, but I'm curious about MS's 'local'
speech SDK. I haven't had much luck with the 5.1 SDK under .NET. There
was a v5.2 mentioned somewhere that had more .NET support, but it seems to
have disappeared. Do you happen to know if anything new is imminent?

_B

 

[Derrick Coetzee [MSFT]]

I've heard of subtle bugs in .NET mixed mode in general. It's frustrating
in that so much work went into the mixed mode bridge, and it's difficult
to trace problems. Smaller, or unstressed models of the code work fine.
I thought maybe it was a task prioritization thing, as the access to the
mixed mode code occurs in a thread. Strangely enough, increasing the
thread priority makes the code *less* reliable. I'm not getting runtime
errors or exceptions--just wrong results. Very counterintuitive.
[ . . . ]
However, if the .NET mixed-mode DLL has inherent problems, as in:

http://msdn.microsoft.com/library/d...stechart/html/vcconMixedDLLLoadingProblem.asp

..then I suppose I'll have to give up on it.

Although you don't experience deadlock, corruption is possible if
static data such as globals and class variables are not initialized
correctly, which is a possible effect of the loading problem. It also
seems to fit your experience of having problems only during stress
conditions:

"[D]eadlock situations are always possible with mixed DLLs, even though
they are often quite rare in practice. The worst part of this is that
mixed DLLs that happen to work on most systems can begin deadlocking if
the system is stressed, the image is signed [...], hooks are installed
into the system, or the behavior of the runtime changes through service
packs or new releases."

Unfortunately it's impossible to avoid the loading problem in any
released versions of the .NET Framework so far. If it's important that
your program starts correctly without deadlock, this may already be
enough reason to avoid using mixed DLLs.

If you still want to try to make the mixed DLL work, make sure you've
followed the steps of this KB to remove the entry point and manually
initialize all static data:

http://support.microsoft.com/Default.aspx?id=814472

Unfortunately, the inner C
DLL is very messy, with lots of typedefs and structs that would be tough
to marshal via PInvoke. The fallback plan may be to encapsulate the C DLL
in an unmanaged C++.NET class to simplify the interface, and use PInvoke
to access that.

This seems workable. For transmitting larger amounts of data, you may
also consider using shared memory, shared files, or even local network
communication.

I've also written a completely unmanaged version of the code which works
fine under run-time stress. In other words, I've got lots of clues, all
pointing in different directions. <g>

If you don't have a compelling reason to provide a .NET interface, such
as language interoperability, you may consider simply using your
unmanaged interface, and eschewing .NET altogether.

Re MS Speech server: [ . . . ] There
was a v5.2 mentioned somewhere that had more .NET support, but it seems to
have disappeared. Do you happen to know if anything new is imminent?

I'm afraid I'm involved only with the server product, and so I don't
know about this, but I will try to contact someone who works on the
Speech SDK to answer your question.

 

[Derrick Coetzee [MSFT]]

Wow. I would agree wholeheartedly. What was .NET created to solve in
the first place? Shitty programmers! So, if you're not a shitty
programmer, you don't need managed code.

Well, I meant avoiding it in this particular application, where there's
a strong need for interaction with legacy code, and an unmanaged version
is already available. In general, I would suggest that managed code be
preferred because it detects and statically prevents a variety of errors
that both inexperienced and experienced programmers often make while
simplifying complex and error-prone issues like memory management,
language inoperability, and interprocess communication. But I have a
feeling you won't be easily convinced.

 

[Severian]

If you don't have a compelling reason to provide a .NET interface, such
as language interoperability, you may consider simply using your
unmanaged interface, and eschewing .NET altogether.

Wow. I would agree wholeheartedly. What was .NET created to solve in
the first place? Shitty programmers! So, if you're not a shitty
programmer, you don't need managed code.

BTW, VC.NET, at least 2003, allows you to create actual, real C and
C++ programs, for the most part. (But don't expect C99 support any
time this millennium).

 

[_BNC]

Wow. I would agree wholeheartedly. What was .NET created to solve in
the first place? Shitty programmers! So, if you're not a shitty
programmer, you don't need managed code.

I've been programming in C++ for many years, but I find it tedious
compared to C# and .NET in general. I still like both, but I'd rather
spend time on algorithms than write function prototypes and deal with
detailed memory allocation and the more arcane aspects of C++. This
particular app needs to make use of SQL, XML, and a lot of other things
that have gone together quickly and smoothly under .NET/C#. I doubt that
would have been the case with VC++/MFC.

For a change, I can look at my code and tell what it's doing pretty
easily. Except, ahem, in this particular case. <g>

If there was an unmanaged version of C# with similar library, I might be
persuaded to port over to unmanaged code, but I think that would take at
least a couple months with the current code.

_B