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
