Jim Blandy :jimb Reporter
	Description • 10 years ago

Making a compartment a Debugger's debuggee need not disable the IonMonkey JIT in that compartment altogether.

At the very least, we could invalidate only those frames on which Debugger performs some operation that an Ion frame can't support. For example, evaluating an expression in a frame's scope that stores a value of a previously unseen type in a local variable necessarily entails bailing out that frame; but extracting a simple backtrace, including source positions and callee names, should have no effect on the frames' representation.

Setting a breakpoint in a script might force that script into baseline; but there's no need to throw away all the IonMonkey scripts in the compartment as soon as it becomes a debuggee.

	Jim Blandy :jimb Reporter
	Comment 1 • 10 years ago

Ideas for unit tests:

- If Ion has inlined a function g into a loop in g's caller f, then we should check that each call to g gets a distinct Debugger.Frame instance. In other words, even though the implementation isn't actually creating any new structure for each entry into g --- it's just using a portion of the same real frame  for each entry into the inlined code --- Debugger must be able to distinguish each invocation.

- If Ion has JITted a function with a loop containing a let block, then Debugger should see a distinct Debugger.Environment instance for each entry into that let block.