|
| pinned data and garbage collection |
|
|
|
|
| Messages |
|
Related Types |
This message was discovered on microsoft.public.dotnet.framework.performance.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.
| Fuzzy |
Does anyone have any detailed insight on how pinned data for unsafe
code really affects memory allocation and garbage collection over the
life of the application?
I know that pinned data cannot be moved in a garbage collection. So,
if a garbage collection occurs while some code is inside a unsafe
"fixed" block, the pinned data will not be relocated and the managed
heap becomes fragmented. Doesn't future memory allocation now have to
take into account the location of the fixed data and revert to the old
malloc method of searching for a memory block of sufficient size?
I have some unsafe code blocks for array manipulations that have
proven to be much faster (in small isolated time tests) than using
default array bounds checking for every access. However, if my
garbage collection and future allocations slow down because of it, I
may not be better off after all.
Does anyone have any details of how this works?
|
|
|
| |
|
| |
| |
| Chris Lyon [MSFT] (VIP) |
Hi Fuzzy
As you've noted, pinned data is not moved by the garbage collector, so having lots of pinned objects sprinkled about the heap will lead to fragmentation and Out Of Memory
Exceptions, since a large enough contiguous block of free memory may not be available at the end of the heap.
As long as your pinned objects are few and are not hanging around for very long, you shouldn't notice any problems, but if you have many such objects, particularly if they're
allocated at different points in the application, you could be Swiss-cheesing your heap.
Yun Jin has a good description on his blog: http://weblogs.asp.net/yunjin/archive/2004/01/27/63642.aspx
Work is being done in version 2.0 (Whidbey) to better manage the heap with respect to pinned objects.
Hope that helps
-Chris
--------------------
[Original message clipped]
--
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.
|
|
|
| |
|
|
| |
| |
| Fuzzy |
Thanks for the info and for the blog link. I don't think it's really
a major issue for me, since I only used pinned objects to speed up the
accumulation of a large array into an accumulator array. I should
never encounter a garbage collection while an object is pinned unless
we decide to multithread the app to enable calculations during
database/disk reads.
But, the more we know, the better we'll be, right?
In the feedback section of the blog, someone implied that future
allocations begin after the pinned objects, that is, no .NET
allocations will occur in the free space between the compacted heap
and the pinned object. Is this correct?
On a related note, in some experimentations with CLRProfiler, I
noticed that there was some free space in the managed heap between
live objects. In this example, NO objects had ever been pinned. Does
anyone have any information on why the GC would decide to not compact
the heap?
|
|
|
| |
|
|
| |
| |
| Chris Lyon [MSFT] (VIP) |
Hi Fuzzy
In v1.0 and v1.1, memory is allocated from the top of the heap, not from in between pinned sections (this makes for really fast allocations). In Whidbey, work is being done to
optimize this.
As for your profiler observation, the GC will only compact if it feels it's necessary. Based on your memory allocation profile, the GC may decide it's too expensive to compact, or
even collect when an object goes out of scope. The GC is self-tuning, so it's not really possible to predict its behaviour.
-Chris
--------------------
[Original message clipped]
--
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.
|
|
|
| |
|
|
| |
|
|
|
|
|
|
|
|
|
|
BootFX
Reliable and powerful .NET application framework. |
|
|
|
|
|
|
