There are also a bunch of phases in backend codegen that take a bunch of time. (To wit, IonBuilder doesn't run for OdinMonkey.) From profiling asm.js, phi-removal and register allocation are the expensive phases. Unfortunately, each compilation step has it's own driving loop. I think one nice pinch point (that is checked between each phases) is MIRGenerator::shouldCancel; the name even lines up.
----- Original Message ----- > IonBuilder::traverseBytecode() should probably have an operation > callback check. > > -David > > On 04/15/2013 03:49 PM, Nicolas B. Pierron wrote: > > On 04/14/2013 11:41 PM, Nicholas Nethercote wrote: > >> Hi, > >> > >> For https://bugzilla.mozilla.org/show_bug.cgi?id=842800 I'm > >> interested > >> in adding more checks of SpiderMonkey's operation callback in > >> potentially long-running operations. For example, when running > >> the > >> asm.js Unreal demo, parsing takes several seconds, so in my patch > >> I > >> added a check after the parsing of each statement. > >> > >> I'm also seeing that IonMonkey compilation can take a while on the > >> demo. Is there a loop or loops in IonMonkey that are good > >> candidates > >> for adding operation callback checks? > > > > IonMonkey compilation is currently sequential for the IonBuilder > > phase > > and the CodeGenerator::link phase. All the rest might run in a > > separate > > thread (or not in case of mono core architectures). > > > > Before the compilation we allocate a lifo-alloc which got extend if > > needed by the compilation. As far as I know, everything which goes > > into > > the lifo-alloc is considered as dark-matter from the about:memory > > point > > of view. > > > > I am not sure what you are trying to look at but what might be > > interesting would be to look at the usage of the lifo alloc. It > > would > > be safe to do it at the creation of each basic block, and in > > MIRGenerator::shouldCancel (called at each loop iteration on basic > > blocks) if it is safe to report such status from another thread. > > > > _______________________________________________ > dev-tech-js-engine-internals mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
