What happens if exception is thown within a fixed block?

[ms news group]

What happens if exception is thown within a fixed block? Will the pinned
memory buffer get unpinned? and if the pinning pointer points to a managed
memery buffer allocated within the throwing function, will the memory buffer
get garbage-collected finally?

I check the language spec, also searched the internet, found nothing
regarding this question.

 

[Jon Skeet [C# MVP]]

What happens if exception is thown within a fixed block? Will the pinned
memory buffer get unpinned? and if the pinning pointer points to a managed
memery buffer allocated within the throwing function, will the memory buffer
get garbage-collected finally?

I check the language spec, also searched the internet, found nothing
regarding this question.

Which memory buffer do you mean? Could you given an example? As far as
I'm aware, the fixed statement just makes sure that during the course
of the block, the variable's location in memory is not changed and the
object referred to (where appropriate) is not garbage collected.

If a managed memory buffer is allocated, it will be subject to garbage
collection when it's not pinned any more - that needn't happen as soon
as the fixed statement finishes.

 

[ms news group]

Thanks Jon.

Let's have simple example here:

void dd()
{
byte [] buffer = new byte[1]

(fixed byte * pb = &buffer)
{
if( sometest())
goto outofblock;
else
throw new exception();
}

outofblock:

}

For the code above, I am only sure that the "goto" statement will unpin the
pb, but will the "throw" also do unpin?
In other words, is this "fixed" block similar to a "lock" block, in that a
try/finally block is actually in place to release the "pinning" or
"locking"?

 

[Jon Skeet [C# MVP]]

Let's have simple example here:

For the code above, I am only sure that the "goto" statement will unpin the
pb, but will the "throw" also do unpin?
Yes.

In other words, is this "fixed" block similar to a "lock" block, in that a
try/finally block is actually in place to release the "pinning" or
"locking"?

I don't think it works quite like that. I *think* the GC just looks at
where a thread's current execution point is and works out whether or
not it's in a fixed region when it considers whether or not it can move
things.

 

[Willy Denoyette [MVP]]

I don't think it works quite like that. I *think* the GC just looks at
where a thread's current execution point is and works out whether or
not it's in a fixed region when it considers whether or not it can move
things.

The GC doesn't have to do that, when the fixed block is entered, the object
is registered in the handle table as "pinned", when the scope is left (say
when an exception is thrown) the pinned handle gets removed from the handle
table, so, when the GC comes along he's free to move the object.

Willy.

 

[ms news group]

Thanks.

I dont really mean that a try/finally mechanism is behind the scene. I am
only concerned with the question whether the pinned block get unpinned
regardless how excecution flow leave the block, be it normal or unnormal.
From what you told me, it seems so, But anyway, I think this is a
legitimite question, and MS perhaps should make this point clear in its doc
or spec.

 

[Willy Denoyette [MVP]]

Thanks.

I dont really mean that a try/finally mechanism is behind the scene. I am
only concerned with the question whether the pinned block get unpinned
regardless how excecution flow leave the block, be it normal or unnormal.
From what you told me, it seems so, But anyway, I think this is a
legitimite question, and MS perhaps should make this point clear in its
doc
or spec.

The ECMA-334 "C# Language Specification" is quite clear about this, from :

27.6 The fixed statement

....
For each address computed by a fixed-pointer-initializer the fixed statement
ensures that the variable
referenced by the address is not subject to relocation or disposal by the
garbage collector for the duration of
the fixed statement.
....

Willy.

 

[ms news group]

hehe,
Does this "For each address computed by a fixed-pointer-initializer the
fixed statement
ensures that the variable referenced by the address is not subject to
relocation or disposal by the
garbage collector for the duration of the fixed statement."
directly leads to "also ensure that the variable get unpinned after leaving
the scope, either normally, or unnormally in the case an exception is thronw
in the scope."?

 

[Jon Skeet [C# MVP]]

Does this "For each address computed by a fixed-pointer-initializer the
fixed statement
ensures that the variable referenced by the address is not subject to
relocation or disposal by the
garbage collector for the duration of the fixed statement."
directly leads to "also ensure that the variable get unpinned after leaving
the scope, either normally, or unnormally in the case an exception is thronw
in the scope."?

Well, it certainly doesn't imply that the "fixedness" has any impact
outside the duration of the fixed statement.

It's not a direct proof, but I'd say it's enough to be pretty
confident.