On Sat, Jul 25, 2009 at 8:29 PM, Subramanya Sastry <[email protected]>wrote:
> > > But there is a way out of this. Yehuda and I talked a bit about it and >> realized that if we could inspect the target method whenever we're >> calling a block, we could determine whether a full heap scope would be >> needed. There are only three constructs that would trigger this >> potential: >> >> * A block argument (&arg) in the parameter list, because it's >> capturing the block for later use >> * A zsuper call (no-arg, no-parens super), because that call could >> capture the block for later use >> * If the call itself is Proc.new, proc, or lambda, because it's >> capturing the block (or -> in 1.9) >> * Any eval-like call (binding, eval) > > > Also send with a target that is not resolveable at compile time + any > aliased method calls that might resolve to an eval or a send. > I think it would be ok to flush all of the bytecode when send was aliased (which never happens). We could consider send with an unresolvable target to be "dangerous". The key is that dangerous methods are not all that expensive; they simply check a flag to check whether they need to retrieve backref info etc., so if they don't have to, the additional cost is just a simple boolean check (vs. the cost of instantiating a frame for EVERY call). > > > -S. > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325
