On Fri, Jul 24, 2009 at 9:34 AM, Ola Bini<[email protected]> wrote:
> Subramanya Sastry wrote:
>>
>>
>> So, the real question here boils down to the previous one: can we safely
>> determine what local variables are captured by closures? In that sense,
>> this is not a new special case that we need
>
> No, that's not really possible. Seeing as you can do something like this:
>
> def foo(n, x)
> proc do
> n + 1
> end
> end
>
> b = foo(42, "blarg")
>
> eval("puts x", b)
It occurs to me today that the vast majority of such cases are
read-only, so lifting the extra variables to the heap store only for
read purposes may be an acceptable degradation of Ruby features. Or it
may not.
The idea Yehuda came up with, Ola, was that if we can inspect the
target method we can determine whether it only uses the block in
"safe" ways, or whether it could use it in "unsafe" ways. So if the
target method has a &block arg, a call to eval-like methods, or a call
to zsuper, the block escapes that method and could potentially be used
as a binding. If it doesn't use the block at all or only yields to it,
we know that the block is only used in safe ways.
And again, a lot of this is still only consider safe static
optimizations. If we could record at the point of block creation in
the interpreter some profiling information that says whether the block
is ever used in an "unsafe" way, we could potentially provide a fast
path. Given the potential for runtime profiling to advise compilation,
the only real complications for us become lack of OSR and inability to
lift local variables from methods higher in the call stack (being
another case of OSR, really, and both are side-effects of a lack of
access to the real stack).
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
