On 04/14/2015 08:31 PM, madhukar.kedl...@gmail.com wrote:
For the past few months I have been working on using offline type profile
information to avoid bailouts in SM. During my experiments I came across
Bailout_DuringVMCall and was not able to trace what exactly caused it.
I was able to reproduce these bailouts using simple examples where I changed
the type of a global variable or shape of an object in a hot function after a
few thousand invocations of it. Ideally, the bailout type for such a code
should be either Bailout_TypeBarrierV or Bailout_ShapeGuard. But I see
Bailout_DuringVMCall being generated. Is it because the hot function gets
inlined into another hot function and there is no what to figure out which
bailout occurred?
This is unfortunately the placeholder for both JS and native function calls.
This can be interpreted as “the generated code got invalidated”.
Sadly, many things can produce code invalidations, and the location of the
bailout does not discriminate the reason of it. This bailout is just here
to ensure that we no longer execute the code which is now un-safe, as it is
based on assumptions which are no longer holding.
Tracing the reason of the invalidation would be nice, and might be doable by
instrumenting calls to addPendingRecompile[1].
[1]
https://dxr.mozilla.org/mozilla-central/search?q=addPendingRecompile&case=true
--
Nicolas B. Pierron
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
