On Sun, Jul 26, 2009 at 9:13 AM, Thomas E Enebo <[email protected]> wrote:
> 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). My proposal to Charlie was not the "blob" idea but rather a custom call protocol that knows how to return the extra information via a thread-local slot. If that protocol also knew how to check a flag slot, it would be possible to use the custom protocol without much penalty in cases where deopt was possible (:===). Even if we had to *always* check a flag, it would be cheaper than having to always allocate a frame (although I'm pretty sure we can start to carve out large swaths of cases where we don't have to check the flag). > If I can jar my memory, then I will update this thread... It would probably be pretty easy to catch by simply deleting anything but the last frame and seeing what breaks ;) -- Yehuda > > > -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 > > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325
