When executing a given piece of code, whenever you call a standard function the execution time is slightly higher than dumping there the code contained into that function. Dumping every time the whole code contained in a function is on the other end unmainteinable because it obviously leads to a whole mess of duplication of … Read more
You could use MethodImplAttribute and specify MethodImplOptions.NoInlining. [MethodImpl(MethodImplOptions.NoInlining)] void YourMethod() { // do something } Note that this still doesn’t guarantee that you can get at the actual calling method as seen in the source code. Your method won’t be inlined, but your method’s caller could be inlined into its own caller, etc etc.
You can use String.intern() to get the desired effect, but should comment your code, because not many people know about this. i.e. public static final String configOption1 = “some option”.intern(); This will prevent the compile time inline. Since it is referring to the exact same string that the compiler will place in the perm, you … Read more
It is a jitter implementation detail, the x86 and x64 jitters have subtly different rules. This is casually documented in blog posts of team members that worked on the jitter but the teams certainly reserve the right to alter the rules. Looks like you already found them. Inlining methods from other assemblies is most certainly … Read more
A couple of the other answers have suggested that only final methods can be inlined – this is not true, as HotSpot is smart enough to be able to inline non-final methods so long as they haven’t been overridden yet. When a class is loaded which overrides the method, it can undo its optimisation. Obviously … Read more