life-time pinning. vs Global heap

  • Thread starter Thread starter TheMadHatter
  • Start date Start date
T

TheMadHatter

I am very sorry to bring a topic up that has been beaten with an ugly
stick..... but...

If I want to "fix" an byte array for the life time of a program would it be
better allocating it on the unmanaged heap?

Yes I know that if I am to pin the object for long periods of time, that it
would be best to do it at the very initial start of the program so that it
prevents some fragmentation of the managed heap.

Thanks in advance for your thoughts on the matter.
 
Oops, sorry for the confusion....
I am using the array in an unsafe context. (via pointers.)
I do not want to continuously use the fixed(byte* ptr = myArray) statement,
so that leaves pinning via GCHandle, or allocating on the
unmanage heap.

Thanks for the responce.
 
With all due respect, not wanting to use the fixed statement is a very,
very poor reason to keep something pinned in memory like this.

Using an unmanaged buffer is only going to help if you are not going to
access the memory outside of an unsafe context. In that case, you would
have to marshal the memory block back to managed code (and then back to
unmanaged when you are done making changes to it, as well as more than
likely protect access with a lock, if concurrency is a concern).

Why do you not want to use the fixed statement?
 
Reasoning: (for better or worst)
The byte array is used throughout the life time of the program,
and would have to be fixed -least- every 20ms for processing.
The Idea is that the array would be up and out of the way from
the garbage collector, because there realy isnt a point in including
it in the gc process.

I know the fixed statement doesnt incurr much at all for pinnning,
atleast until the garbage collection cycle is triggered when the
object is pinned.

Nicholas Paldino said:
With all due respect, not wanting to use the fixed statement is a very,
very poor reason to keep something pinned in memory like this.

Using an unmanaged buffer is only going to help if you are not going to
access the memory outside of an unsafe context. In that case, you would
have to marshal the memory block back to managed code (and then back to
unmanaged when you are done making changes to it, as well as more than
likely protect access with a lock, if concurrency is a concern).

Why do you not want to use the fixed statement?

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

TheMadHatter said:
Oops, sorry for the confusion....
I am using the array in an unsafe context. (via pointers.)
I do not want to continuously use the fixed(byte* ptr = myArray)
statement,
so that leaves pinning via GCHandle, or allocating on the
unmanage heap.

Thanks for the responce.
Click to expand...
Click to expand...
 
This is the kind of situation where you really have to test it out both
ways in order to see what the performance impact is (because that is the
issue here, right?). Because we don't know anything about the allocation
patterns of your app, it's impossible to tell how often a GC would occur,
and how repeated fixed statements would be impacted versus pinning the array
once.

It's something you are going to have to measure, and compare for
yourself.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

TheMadHatter said:
Reasoning: (for better or worst)
The byte array is used throughout the life time of the program,
and would have to be fixed -least- every 20ms for processing.
The Idea is that the array would be up and out of the way from
the garbage collector, because there realy isnt a point in including
it in the gc process.

I know the fixed statement doesnt incurr much at all for pinnning,
atleast until the garbage collection cycle is triggered when the
object is pinned.

Nicholas Paldino said:
With all due respect, not wanting to use the fixed statement is a
very,
very poor reason to keep something pinned in memory like this.

Using an unmanaged buffer is only going to help if you are not going
to
access the memory outside of an unsafe context. In that case, you would
have to marshal the memory block back to managed code (and then back to
unmanaged when you are done making changes to it, as well as more than
likely protect access with a lock, if concurrency is a concern).

Why do you not want to use the fixed statement?

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

TheMadHatter said:
Oops, sorry for the confusion....
I am using the array in an unsafe context. (via pointers.)
I do not want to continuously use the fixed(byte* ptr = myArray)
statement,
so that leaves pinning via GCHandle, or allocating on the
unmanage heap.

Thanks for the responce.

:

The word "fix" is somewhat confusing here. If you really only need to
have
the byte array available for the lifetime of the appDomain, you can
just
add
the static modifier. Or, you could create a byte array property and
make
it
readonly.
--Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
MetaFinder: http://www.blogmetafinder.com


:


I am very sorry to bring a topic up that has been beaten with an
ugly
stick..... but...

If I want to "fix" an byte array for the life time of a program
would
it be
better allocating it on the unmanaged heap?

Yes I know that if I am to pin the object for long periods of time,
that it
would be best to do it at the very initial start of the program so
that
it
prevents some fragmentation of the managed heap.

Thanks in advance for your thoughts on the matter.
Click to expand...
Click to expand...
Click to expand...
 
My personal experience is that the best bet is to:
- Allocate a big byte array at the start of your program. This ends up
coming out of the Large Object Heap.
- Pin the array using the GC Handle.
- use ArraySegment<T> to partition the big array during the lifetime of your
app...
 
Thanks for your thoughts on the matter.



Nicholas Paldino said:
This is the kind of situation where you really have to test it out both
ways in order to see what the performance impact is (because that is the
issue here, right?). Because we don't know anything about the allocation
patterns of your app, it's impossible to tell how often a GC would occur,
and how repeated fixed statements would be impacted versus pinning the array
once.

It's something you are going to have to measure, and compare for
yourself.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

TheMadHatter said:
Reasoning: (for better or worst)
The byte array is used throughout the life time of the program,
and would have to be fixed -least- every 20ms for processing.
The Idea is that the array would be up and out of the way from
the garbage collector, because there realy isnt a point in including
it in the gc process.

I know the fixed statement doesnt incurr much at all for pinnning,
atleast until the garbage collection cycle is triggered when the
object is pinned.

Nicholas Paldino said:
With all due respect, not wanting to use the fixed statement is a
very,
very poor reason to keep something pinned in memory like this.

Using an unmanaged buffer is only going to help if you are not going
to
access the memory outside of an unsafe context. In that case, you would
have to marshal the memory block back to managed code (and then back to
unmanaged when you are done making changes to it, as well as more than
likely protect access with a lock, if concurrency is a concern).

Why do you not want to use the fixed statement?

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Oops, sorry for the confusion....
I am using the array in an unsafe context. (via pointers.)
I do not want to continuously use the fixed(byte* ptr = myArray)
statement,
so that leaves pinning via GCHandle, or allocating on the
unmanage heap.

Thanks for the responce.

:

The word "fix" is somewhat confusing here. If you really only need to
have
the byte array available for the lifetime of the appDomain, you can
just
add
the static modifier. Or, you could create a byte array property and
make
it
readonly.
--Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
MetaFinder: http://www.blogmetafinder.com


:


I am very sorry to bring a topic up that has been beaten with an
ugly
stick..... but...

If I want to "fix" an byte array for the life time of a program
would
it be
better allocating it on the unmanaged heap?

Yes I know that if I am to pin the object for long periods of time,
that it
would be best to do it at the very initial start of the program so
that
it
prevents some fragmentation of the managed heap.

Thanks in advance for your thoughts on the matter.
Click to expand...
Click to expand...
Click to expand...
 
Thanks Chris.
I didnt know about the ArraySegment<T> :D

Oh yea... and the Large Object Heap.....
It has a tendency not to move objects as well. humm.....

Once again thanks for the insightful answer. :) :) :)
 
Don't assume that because the LOH isn't compacted today, that it won't be in
the future.

Be sure to pin whatever you allocate, so that you're future proof. It would
suck to have a customer installed a Service Pack, and have your app break.
 
Yes of course.

I attempted to imply that the gc doesn't try very often
to move large objects so the gc performance penelty
for pinnin will be reduced.

Thanks again.
 
Hello, this was in 2008, has anything been offer by msft to solve this issue?


Recap:
Basically how do we pin an object on the global scope? and not only on tiny scope
Another way to solve this: Is there a way to be notify when the GC has move the array? so may be I can recompute my pointer position....
Or Is there a way to know when the pointer doesn't point to a managed object anymore?
I feel I can solve this issue for double with GCHandle.Alloc, but what do I do for date? I will guess the date to long conversion will be too costly?
I can't use GCHandle.Alloc with DateTime as DateTime is un-bittable, why?
Is there a way to tell the GC to not compact the memory?
Is there a way to not allow the GC to promote a long live object as Gen 2?
I could of course create some large object so they are not compacted. but the definition might change thought time....
(The large object heap contains objects that are 85,000 bytes and larger. Very large objects on the large object heap are usually arrays. It is rare for an instance object to be extremely large. )

Thanks for your help

w
 
Back
Top