I don't know, I can only speculate. It seems like they are reusing the
same buffer, presumably because it will be promoted to an older GC
heap generation after a while, and it probably hurts less to pin
things on gen2 than gen0 for example.

As to why they are manually pinning, perhaps it's cheaper to
explicitly pin once and pass the same IntPtr (opaque to the marshaler)
to native code, than to rely on the marshaler to pin/unpin for every
call.

I don't know why they aren't doing the same thing for the byte buffer,
but then I haven't really studied the usage pattern. Perhaps it's the
fact that the strings have to be decoded from UTF8 anyway so such an
optimization might not make sense in this case. Hopefully the ASP.NET
team have a good reason for doing it the way they are.

Mattias

Hi

Based on my understanding, for synchronous call, the GC will have no chance
to collected it.
e.g.
byte[] bts = new byte[3];
int rt = UnmanagedPInvoke(bts);
//until the rt is return the bts is still alive, the bts will not be
collected.

But for asynchronous scenario, it is better to pin the memory to ensure the
byte array will not be removed in case the byte array var is out of
lifetime.

Hope this helps.

Best regards,

Peter Huang
Microsoft Online Partner Support