On Fri, Jan 17, 2014 at 11:26 PM, Jim Blandy <[email protected]> wrote:
> It seemed to me that we could minimize the actual lookups by representing > code positions using a type that was quick to construct, and put off doing > the lookups until asked. This AbstractCodePtr class could store an > <IonScript, displacement> pair, or a <JSScript, bytecode offset> pair, or > an actual <URL, line, column> - and mutate itself from lazier to more > reified forms on demand. > Note that you need something similar for Baseline. Same trick though: BaselineScript::icEntryFromReturnAddress does a binary search to go from a return address to a bytecode pc, you could lazify that. An <IonScript, displacement> pair can map to multiple frames due to inlining. For inline frames, InlineFrameIteratorMaybeGC::findNextFrame() reads the bytecode pc from the snapshot and it gets the JSScript from the callee Value. The latter is a problem: the callee may be stored somewhere on the stack or in a register, so you can't do this lazily (the callee used to be a constant JSFunction*, but this is no longer the case since bug 859609). To fix this, snapshots could store the JSScript explicitly, like the bytecode pc. (Or an index into a list of JSScripts stored in the IonScript.) > In IonFrames, a bit in the descriptor would work for this, if one is > available; pushing descriptors with an extra zero bit next to the > constructing bit should have no runtime cost. The constructing bit is not used (and that comment should be updated). We determine this from the caller's pc (frame is constructing if caller's pc is a JSOP_NEW). So a frame descriptor has 4 bits for the type and 28 bits for the size, I think you can steal a bit from that. Jan _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
