[Mono-dev] mono / llvm inlining situations (or failures thereof)
kumpera at gmail.com
Mon Jul 16 17:45:43 UTC 2012
On Mon, Jul 16, 2012 at 1:59 PM, Leszek Ciesielski <skolima at gmail.com>wrote:
> On Mon, Jul 16, 2012 at 6:20 PM, Rodrigo Kumpera <kumpera at gmail.com>
> > Hi Jonathan,
> > There are a few factors that affect inlining.
> > We don't inline more than 10 levels deep, but I doubt this is your
> > We don't inline synchronized methods, methods that belong to MarshalByRef
> > classes or method that do exception handlibg. Not your case, probably.
> > We only inline methods smaller than 20bytes of IL. It might be your case.
> > You can control this with the MONO_INLINELIMIT env var or use the
> > AgressiveInlining compiler hint.
> > We don't inline calls to classes that need their class constructor to be
> > ran. Might be your case.
> > We don't do inlining when generics are involved. Doesn't look to be your
> > case;
> > And, finally, we don't inline methods that call other methods (including
> > constructors).
> > The last restriction does look to be your issue. We do it due to a pair
> > issues, first because it produces broken stacktraces
> > and because it breaks calls that check caller assembly. Both can be
> fixed if
> > mono had support for inlining maps.
> If that restriction is a major issue - doesn't the JVM solution work
> good enough here? Just leave enough frames on the stack that
> inter-assembly calls are interweaved as they should, leaving one frame
> per assembly in the extreme case. Or is that a more complicated issue
> than Java has with inlining?
Not sure what the suggestion is here. The JVM does limit inlining in this
fashion to make it's security sandbox work. We don't do it due to the
two stated restrictions, which are unrelated. And, BTW, inline maps
is what HotSpot uses to not break backtraces ;)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list