I think it's important to think about the features in terms of their actual requirements and try to remove the idea of "frame" from your mind. In my opinion (which is admittedly limited), the only reason that we've been thinking about this feature in terms of frames (as opposed to a special call protocol) is that MRI implements it that way. In this case, there can be only one $1 (for instance), which is provided by the callee, so there can be no need to have many levels of information. Or is there a case I'm missing?
-- Yehuda On Sun, Jul 26, 2009 at 2:40 AM, Thomas E Enebo <[email protected]> wrote: > On Sat, Jul 25, 2009 at 11:44 PM, Charles Oliver > Nutter<[email protected]> wrote: > > I was talking with Yehuda today and I think we came up with a couple > > solutions for eliminating frames. > > > > The cases where we have problems are: > > > > * All methods that read or write backref > > * All methods that read or write lastline > > * All methods that read or write visibility > > * All methods that have arbitrary access to the binding (eval, binding, > ...) > > * Methods that have closures that do any of these things, or where the > > closure is used as a binding elsewhere > > > > The first three cases could be solved as follows: > > > > Backref and lastline can only be read or written in one of two ways: > > via a Java-implemented core class methods, or via the syntactic > > constructs $~ for backref or $_ for lastline. Visibility can only be > > written by public/private/protected method calls, and only gets read > > by Java code that handles plumbing new methods. All three are scoped > > at the nearest "hard" scoping boundary, like a method or a class, and > > closures within that scope share the same slot (this last point is a > > little fuzzy, but it's good enough for illustration purposes). > > > > Currently, all Ruby code bodies prepare a heap-based structure (Frame) > > for every call, just in case it might be needed. This is in large part > > a reason for remaining slowness in Ruby execution, since even in > > compiled mode we have to prepare this structure on the way in and drop > > it on the way out, even if it's never used. > > > > However it turns out that the methods that read/write > > backref/lastline/visibility are *leaf* methods; there's exactly one > > hop to get to the native code that manipulates them. > > > > I believe it's time we had an additional call path that can include a > > "Blob" object that contains these fields. With this call path, any > > time one of these "potentially dangerous" method names is seen in > > code, we could *lazily* prepare the Blob and pass it down the call > > path. It would eventually arrive in the target method and be used to > > do the read/write as though it were an "out" variable. So this > > immediately isolates those frame fields' overhead to cases where > > they're potentially going to be called (barring aliasing effects). > > > > If we lifted the lookup of the target method all the way to the call > > site, we could physically inspect it to see if it *is* one of those > > "dangerous methods" and only pass the Blob in those cases. > > I thought we knew of a case where we need two levels of call stack > info? It is escaping me now. I know we have talked about this in the > past and I thought the conclusion was (this was a slightly different > idea we had to just pass all frame info as variables in the call stack > with no blob) that we need last two levels of frame information? > > -Tom > > > If we also added construction and passing of this Blob into the IR, we > > could see whether the Blob is ever subsequently read from or written > > to, and potentially *never* allocate it whatsoever. > > > > I think this is a very simple way for us to safely eliminate some > > framing cost. I'll try to make the idea a bit more concrete. > > > > - Charlie > > > > --------------------------------------------------------------------- > > To unsubscribe from this list, please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > > -- > Blog: http://www.bloglines.com/blog/ThomasEEnebo > Email: [email protected] , [email protected] > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325
