Problem described in appended email. Even if we end up deciding that this behavior is "correct", we need to clearly document it since it is a change from previous and long-standing behavior. Thank you Dave for the hint, you brought me on the right track (don't know whether you can say that in english, seems to be a bad translated german saying). I found the root of this evil. The inlining decision is based on the method VM_Method.hasNoInlinePragma() which calls VM_AnnotatedElement.hasNoInlineAnnotation(). Here isAnnotationDeclared(VM_TypeReference.NoInline) is called. Unfortunately this method compares the classloaders of the give TypeReference and the NoInline Annotation. While the NoInline annotation is within the scope of BootStrapCL, my testmethod is in the scope of SystemAppCL. as they are not equal, the method returns false, and my test is inlined. So far for the analysis. But what can I do to solve this? I introduced a method isNoInlineAnnotationDeclared(VM_TypeReference.NoInline) which leaves out the classloader check. But I cannot estimate the long term quality of this. So whom ever might read this on a search for solutions: Be careful! Good luck and thx to Dave Christian Rüdiger On 10/31/07, David P Grove <groved@us.ibm.com> wrote: > > > jikesrvm-researchers-bounces@lists.sourceforge.net wrote on > 10/31/2007 11:21:54 AM: > > > Hello everybody, > > > > I wrote a few methods, which should be compiled in a special way, and > > I want to check the HIR output of those methods. Unfortunately they > > get inlined. And even more unfortunately I cannot switch inlining of, > > as i am inlinig in the testmethod myself. > > > > Means: I need inlining mechanisms activated, but want the compiler not > > to inline one special method. > > > > I expected the "@NoInline"-annotation the best way to explicitly > > prevent methods from being inlined, but the compiler seems to ignore > > it. Did I miss anything? > > You are right that the NoInline annotation is supposed to do exactly what > you want. I have this vauge feeling I saw the same bug about a month ago > with the @Uninterruptible annotation. I have a sneaking suspicion that the > problem is somehow related to classloaders (annotations are compared for > equality not just by name, but by classloader too), but I never tracked it > down to be positive that was the problem. > > --dave > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Jikesrvm-researchers mailing list > Jikesrvm-researchers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > >