There are two different issues here: 1) how many frames up a backref goes back to 2) whether it's possible for a method to modify ITS backref but still have a previous backref (in a given thread) still valid in some context
I don't think (2) is actually possible, and (1) is solved by a single thread-local slot, which eliminates the need to care about propagating back up. -- Yehuda On Sun, Jul 26, 2009 at 10:46 AM, Ola Bini <[email protected]> wrote: > Thomas E Enebo 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). >> >> If I can jar my memory, then I will update this thread... >> >> -Tom >> >> >> > I might be wrong, but I seem to remember grep or one of those other common > methods needed more layers of backref. Might have been gsub too. > > Cheers > > -- 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 >>> >>> >>> >> >> >> >> >> > > > -- > Ola Bini (http://olabini.com) Ioke creator (http://ioke.org) > JRuby Core Developer (http://jruby.org) > Developer, ThoughtWorks Studios (http://studios.thoughtworks.com) > Practical JRuby on Rails (http://apress.com/book/view/9781590598818) > > "Yields falsehood when quined" yields falsehood when quined. > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325
