Had no idea about that. Thanks for following it up! On 25 March 2011 11:19, Mark Hurd <markeh...@gmail.com> wrote:
> Thanks for that clarification. However GoogleDesktop found my previous > recollection discussing this was in the Microsoft NewsGroups, which > now Googling for the subject of that exchange "Reflection and compiler > inlining" found this other reply: > > On 2009-12-11 6:18, Alex Clark wrote: > > Yes, because any method that calls MethodBase.GetCurrentMethod() will not > be > > inlined. This is because .GetCurrentMethod() includes a StackCrawlMark, a > > special magical enum for methods that need to walk the stack (like > > .GetCurrentMethod() predictably needs, to look for its caller) that > prevents > > the caller from being inlined. Trying to be clever by sticking the call > in a > > delegate like Mark did will not upset this, because methods that call > delegates > > are not inlined either. > > (as retrieved from > > http://www.eggheadcafe.com/software/aspnet/35469613/reflection-and-compiler-inlining.aspx > but there are a number of clones of this info) > > So have things changed or was Alex Clark wrong? > -- > Regards, > Mark Hurd, B.Sc.(Ma.)(Hons.) > > On 25 March 2011 02:40, David Kean <david.k...@microsoft.com> wrote: > > I chased this up with one the devs on the JIT team. He confirmed that the > JIT/NGEN doesn't give this guarantee, both inlining and tail calls can cause > Assembly.GetExecutingAssembly, Assembly.GetCallingAssembly and > Method.GetCurrentMethod to return incorrect results. You can somewhat > mitigate that by marking your method with NoInlining (to prevent inlining) > and NoOptimization (to prevent the JIT spitting out tail calls)[1], however, > it is still possible for this to return incorrect results in certain other > situations. > > > > > http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions.aspx > > > > -----Original Message----- > > From: ozdotnet-boun...@ozdotnet.com [mailto: > ozdotnet-boun...@ozdotnet.com] On Behalf Of David Kean > > Sent: Tuesday, March 22, 2011 10:06 PM > > To: ozDotNet > > Subject: RE: Raising property changed events > > > > Hmm, I'll check internally, but I'd be surprised if we give that > guarantee. We're free to change our inlining policy at any time, in fact, we > did just that in 3.5 SP1 x64 which broke a lot of customers who were relying > on Assembly.GetExecutingAssembly() without explicitly turning off inlining > for the method. > > > > Whether you can repro something now, is not a good indication of whether > we'll continue to support in a future service pack or version - always check > the docs. However, in saying that, the docs don't really make it clear that > this might not work correctly in certain situations. In which case, if we > don't give the above guarantee I'll make sure they call it out. > > > > -----Original Message----- > > From: ozdotnet-boun...@ozdotnet.com [mailto: > ozdotnet-boun...@ozdotnet.com] On Behalf Of Mark Hurd > > Sent: Tuesday, March 22, 2011 9:36 PM > > To: ozDotNet > > Subject: Re: Raising property changed events > > > > On 23 March 2011 15:00, Mark Hurd <markeh...@gmail.com> wrote: > >> I believe it was in this mailing list that we previously confirmed > >> using GetCurrentMethod, even when included in convoluted ways, > >> guarantees the method will not be inlined. > > > > Gmail says GetCurrentMethod has /not/ been mentioned before on this > mailing list since I've been part of it, so I'm remembering that wrong. > > > >> Can you show an example where GetCurrentMethod does not return the > >> expected method? > > > > This request still stands however. > > -- > > Regards, > > Mark Hurd, B.Sc.(Ma.)(Hons.) >
