On Sat, Jul 25, 2009 at 8:35 PM, Subramanya Sastry<[email protected]> wrote:
> On Sat, Jul 25, 2009 at 11:49 AM, Yehuda Katz <[email protected]> wrote:
>>
>> It seems to me that *all* calls to "dangerous methods" are basically leaf
>> calls, because you only need to grab the "frame" information one frame above
>> where the information was added.
>> So you should be able to have each Ruby *thread* allocate a single
>> thread-local slot per "frame" variable plus a flag slot.
>
> I am not sure if this is true, since you can store procs and blocks, pass
> them around, and call them whenever, wherever. In addition, you can have
> multiple instances of a frame for a method be active at the same time, i.e.
> if foo is a method, you could have 100 different instances of foo's
> execution environment in 100 unique frame objects which means you have to
> allocate them on a heap and subject them to GC like any other java object.
>
> Or did I misunderstand what you said here?
For the moment, I'm treating a closure as *mostly* a full deopt, since
there are very tricky features like block-as-binding that we have to
find reliable ways to deal with. This is also how the current compiler
works, doing its full set of optimizations only against methods that
have no eval-like calls and no closures. And I see no problem with
this...a substantial portion of Ruby methods do not have blocks at
all.
Now another aspect of block logic is that if we can determine that a
block is being passed to a known *safe* method, like Array#each, then
we know exactly what semantics are required. We know that there's no
block-as-binding, we know that there's no visibility or backref or
lastline access, and so on. We can get that information either as a
profiled optimization or as a special "each" call site that knows how
to handle Array#each differently from an arbitrary each, but both are
doable and both would show immediate results, including the
possibility of inlining #each logic directly into the caller.
The fact that you can save off a proc and call it repeatedly does not
necessarily impact optimization any more than a normal block...since a
normal block can be turned into a proc in the target method and called
repeatedly. Blocks have a specific and *finite* set of effects that we
need to understand and mitigate, and methods that contain a block will
probably never be as fast and highly optimized as methods that do not
contain blocks, but I think we have a tremendous amount of room to
improve block performance even in light of blocks' peculiar and wilder
characteristics.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
