Diagnostics.StackTrace and NoInlining attribute

This is copied from my post in CSLA forum
http://groups.msn.com/CSLANET/general.msnw?action=get_message&mview=0&ID_Message=26513

In addition to the issue itself, it also gives an example of the benefits of participating key open source projects.


--------------------------------------------------------------------------------
-------------there are others posts before my post below;
-------------please use the above the link to see them
--------------------------------------------------------------------------------

I did some research, and read the following from here: (http://www.springframework.net/doc/reference/html/aop.html )

------------
Generally speaking, a method will be a candidate for inlining when its code is 'small', just a few lines of code (less than 32 bytes of IL). For some interesting reading on this process read David Notario's blog entries (JIT Optimizations I http://blogs.msdn.com/davidnotario/archive/2004/10/28/248953.aspx and JIT Optimizations II http://blogs.msdn.com/davidnotario/archive/2004/11/01/250398.aspx ).

Additionally, when an assembly is compiled with a Release configuration the assembly metadata instructs the CLR to enable JIT optimizations. When compiled with a Debug configuration the CLR will disable (some?) these optimizations. Emperically, method inlining is turned off in a Debug configuration.

The way to ensure that your control flow pointcut will not be overlooked because of method inlining is to apply the System.Runtime.CompilerServices.MethodImplAttribute attribute with the value MethodImplOptions.NoInlining. In this (somewhat artifical) simple example, if the code is compiled in release mode it will not match a control flow pointcut for the method "GetAge".

public int GetAge(IPerson person)
{
return person.GetAge();
}

However, applying the attributes as shown below will prevent the method from being inlined even in a release build.

[MethodImpl(MethodImplOptions.NoInlining)]
public int GetAge(IPerson person)
{
return person.GetAge();
}

----------


Basically, this means all methods that use the following 3 methods’ overload that without property name must use the
[MethodImpl(MethodImplOptions.NoInlining)] attribute.

CanReadProperty() or (boolean);
CanWriteProperty() or (boolean);
PropertyHasChanged();

It seems those overloads do not buy too much. However, considering the attribute can be added mechanically, those overloads can still be useful.

--------------------------------------------------------------------------------
-------------there are others posts before my post below;
-------------please use the above the link to see them
--------------------------------------------------------------------------------
I agree. Because the nature of the unpredictability of inlining optimization, whenever we use the convenient overloads without “property name”, we need to use the NoInlining attribute.

So:

(a) Comment for the convenient methods should indicate that;
(b) The example in PTracker should be changed to use the NoInlining attribute.


--------------------additional note:
Note that this also affect

System.Reflection.MethodBase.GetCurrentMethod().Name

It seems that other than hard coding/code generation, the only way is to use emit-aop. For now, virtual methods are not inlined. Even in the future, when virtual methods are inlined, the aop process will be done before inlining -- I will need more research on this though. I will report the result later.

Also note that the techique used for log4net seems still ok, because that is at class level.