On Sun, Jul 26, 2009 at 5:03 PM, Yehuda Katz<[email protected]> wrote: > 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?
To be honest I am not sure which field it was which I thought we needed two levels of. I just say Frame because that is where the fields in question currently live. The truth a couple of fields like visibility probably should not even exist on frame. We probably should consider breaking out some of these fields before trying the blob idea. I know visibility would be a seldom manipulated stack for instance (it used to be that way). If I can jar my memory, then I will update this thread... -Tom > -- 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 > -- blog: http://blog.enebo.com twitter: tom_enebo mail: [email protected] --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
