GC和固定指针 [英] GC and pinned pointers
问题描述
另一个线程提到了非固定指针作为
Interop错误的可能原因。我想了解更多关于它是如何产生的。我b $ b假设垃圾收集器进行扫描，决定重新分配没有固定的
内存，并且非托管代码的指针变为
无效。
如果一个相当大的应用程序运行在
a P4 300ghz，超过1 gig ram，那么GC运行的频率是多少？我本以为它根本不需要经常运行。
是否还有其他可能的原因导致指针问题无法解决？
_BNC写道：另一个线程提到了非固定指针作为一个可能的原因导致了Interop错误。我想了解更多关于它是如何产生的。我认为垃圾收集器进行扫描，决定重新分配未固定的内存，并且非托管代码的指针变得无效。
IIRC非托管代码只能引用固定对象，GC不允许移动固定对象
，所以非托管指针不会变成
无效。
如果一个相当大的应用程序运行在一台P4 300ghz超过1 gig ram上，那么GC的运行频率是多少？我本以为它根本不需要经常运行。
每次你的应用程序想要分配一个对象时都会执行GC />
和第0代的阈值达到（我认为是256K）。
因此，执行GC的频率取决于应用程序的行为方式。
问候，
Joakim
GC运行次数'' s高度依赖于你的使用模式而不是系统
CPU性能，如果你频繁分配，GC将经常运行很多
。
如果你根本没有分配，GC根本不会运行（除非系统内存运行不足）。
你不应该关心这个数字GC运行时，你必须将你传递给
的指针固定到非托管代码上。
Willy。
" _BNC" < _B ** @ nospam.com>在消息中写道
news：p4 ******************************** @ 4ax.com ...另一个线程提到了非固定指针作为
Interop bug的可能原因。我想了解更多关于它是如何产生的。我认为垃圾收集器进行扫描，决定重新分配未固定的内存，并且非托管代码的指针变得无效。
如果一台相当大的应用程序运行在一台P4 300ghz超过1 gig ram上，那么GC的运行频率是多少？我本以为它根本不需要经常运行。
是否还有其他可能的原因导致指针无法解决问题？
2005年1月12日星期三23:05:39 +0100，Willy Denoyette [MVP]
< wi ******** *****@pandora.be>写道：
GC运行的数量在很大程度上取决于您的使用模式而不是系统
CPU性能，如果您经常分配，GC将经常运行。
如果你根本没有分配，GC根本不会运行（除非系统内存不足）。
你应该不关心GC运行的次数，你必须将你传递给指令的指针固定在所有的非托管代码上。
Willy。
感谢您的回复，Willy。我不是固执地固定
指针......我想知道我是否错过了某个地方。或许
这完全是另一个问题，我不知道。我没有做那么多内存分配。我最初并不认为GC会成为
的罪魁祸首，但由于只有在程序受到压力时出现问题，它才会看起来很可疑。我工作过的小型测试模型
当然运行正常。
我还在努力处理微妙之处
托管到非托管桥。大部分内容似乎与我违反直觉。
例如，使用类似方法的MSDN代码：
http://msdn.microsoft.com/library/de .. .nagedtypes.asp
没有__pin指向非托管结构的指针（参见构造函数：
" city = new CITY;" ）。我想弄清楚为什么那个指针不需要固定
。
我从wrox书中的代码开始我的原始模型
" Visual C ++。NET：C ++开发人员的入门读物（Aravind Corera等，
ISBN 1861005962）。其中概述了在内部非托管代码中使用''同心''/ b $ b类的方法（Center = DLL，然后是
非托管C ++包装器，然后是托管C ++包装器，然后是C＃ ）。他们
也没有将指针固定到非托管C ++包装器上。
我会从一开始就使用PInvoke，但中央DLL是这样的
a一塌糊涂，带有大量模糊的结构和定义的数据类型，它使得b / b
似乎更合乎逻辑地将丑陋的东西封装在
的非托管方面围栏。
我害怕当我很好地处理临时
分层的工作方式时，Whidbey会让它过时我的项目将是
结束。 < g取代; （IOW，真正的问题是某处的愚蠢错误）
_B
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?
_BNC wrote: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
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.
"_BNC" <_B**@nospam.com> wrote in message
news:p4********************************@4ax.com...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?
On Wed, 12 Jan 2005 23:05:39 +0100, "Willy Denoyette [MVP]"
<wi*************@pandora.be> wrote:
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/de...nagedtypes.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
这篇关于GC和固定指针的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
