Hi Andrea,
A quick overview of the Intermediate Representation for JRuby before
talking about possible projects.
This IR has been designed with the following goals in mind:
1. Capture Ruby semantics as accurately as possible without losing
information.
2. Expose primitive operations (ex: a
On Thu, Feb 6, 2014 at 6:49 PM, Subramanya Sastry sss.li...@gmail.comwrote:
On Thu, Feb 6, 2014 at 5:46 PM, Charles Oliver Nutter head...@headius.com
wrote:
I also ran into an issue with how heap variable assignment is being
optimized:
for the closure passed to foo: a = 'here'; foo
On Thu, Feb 6, 2014 at 5:46 PM, Charles Oliver Nutter
head...@headius.comwrote:
A lot more code is working now that I've just opted to back off
specializing anything beyond what the IR does itself.
Makes sense. Let us fix the IR and add any missing info to make sure what
JIT gets is mostly
On Fri, Jan 31, 2014 at 5:56 AM, Charles Oliver Nutter
head...@headius.comwrote:
Ok, so I got frame push/pop working and wanted to move on to binding.
I was under the impression that push/pop binding was basically for
pushing/popping a DynamicScope, but it seems like it's more than that.
For
3 %t_%block_1 = recv_closure
This is only used to receive blk arg which is a Proc and hence an
IRubyObject.
I was baffled for a bit as well how the Interpreter works on this and
realized what was going on when I looked at how this instr. is interpreted.
result = (block ==
I attempted to look at heap-scoping today and ran into a couple things
that kept me from making much progress.
1. Pre/post logic for heap scope and frame
...
I believe we need to move more into explicit call protocols
(instructions to push scope/frame/binding, etc) in the IR, so I can
.
Subbu.
On Sun, Jan 26, 2014 at 9:22 AM, Subramanya Sastry sss.li...@gmail.comwrote:
I attempted to look at heap-scoping today and ran into a couple things
that kept me from making much progress.
1. Pre/post logic for heap scope and frame
...
I believe we need to move more
On Tue, Oct 1, 2013 at 4:20 PM, Charles Oliver Nutter
head...@headius.comwrote:
Many questions!
On Tue, Oct 1, 2013 at 3:41 PM, Jon Zeppieri zeppi...@gmail.com wrote:
- Are NotCompilableExceptions caught somewhere, allowing the
interpreter to carry on? (I did a simple grep for this, but
FYI. This commit also fixes JRUBY-6705.
--
commit 7c3f6426eb26e560f21b2f1905923fa624c4408c
Author: Subramanya Sastry sss.li...@gmail.com
Date: Thu Jun 21 23:43:39 2012 -0500
HEADS UP! Removed all trace of setWithinDefined and isWithinDefined.
* Tested on rubyspecs in 1.8
Please refer to bug: https://jira.codehaus.org/browse/JRUBY-6705
I reduced this bug to the following code snippet. My comments and
questions follow this snippet
--
class Object
def self.const_missing(*args)
I started working on implementing an explicit call protocol last week.
It required me to clean up a few other bits which I did over several
commits since y'day.
I now committed a first cut at AddExplicitCallProtocolInstructions compiler
pass.
I tested this with the interpreter and it seeks to
As part of working on making call protocol a little explicit, I started
making some notes about the call paths and figuring out what can be
optimized, what cannot be, what component is responsible, how much can
interpreter benefit, how much can compiler benefit, etc. Based on this,
I'll work on
will look into this a bit tonight and see if I can get basic binding
logic implemented in IR2JVM. Thanks, Subbu!
On Mon, May 7, 2012 at 8:48 PM, Subramanya Sastry sss.li...@gmail.com
wrote:
I started working on implementing an explicit call protocol last week.
It required me to clean up
to see how far it can be
pushed.
Subbu.
On Fri, May 4, 2012 at 12:39 AM, Charles Oliver Nutter
head...@headius.comwrote:
On Fri, May 4, 2012 at 6:27 AM, Subramanya Sastry sss.li...@gmail.com
wrote:
I was making my case on the assumption that access to $~ is always
through
Ruby code
So, Tom and I have wondered on and off about how to represent/handle $-vars
better. And last week, when Charlie, Tom, and I met, we talked about it
some more, where it occured to us that $-vars are not that different from
local variables. Tom had also indicated earlier that $1 .. $n are just a
Hi folks,
On Saturday, EngineYard published my blog post about IR along with current
status, and future plans.
Thought it might be of interest to folks on this list. Feel free to post
questions/concerns/comments, if any.
http://www.engineyard.com/blog/2012/oss-grant-roundup-jruby-runtime/
* There is a general problem with defined? IR. I based this on the ast
compiler which has all defined? logic inlined -- when I started
implementing defined? IR, I couldn't fully follow the logic and so blindly
translated that into IR but when I was 2/3rds done and had figured out the
logic more,
Nutter* head...@headius.com
Date: Sun, Apr 22, 2012 at 8:58 PM
To: Subramanya Sastry sss.li...@gmail.com, Thomas Enebo
tom.en...@gmail.com
https://gist.github.com/2466877
Good old fib again. -X+CIR is faster than -X+C but it's not doing all
appropriate call site guarding. The main change I
Awesome! -Subbu.
On Tue, Dec 6, 2011 at 7:44 AM, Charles Oliver Nutter
head...@headius.comwrote:
In order to make it a bit easier and less daunting to contribute to
RubySpec, I'm proposing (and have mostly already made) a minor change
in our process.
* Instead of pulling directly from
* IR work. Where do we stand? Is it possible we might turn it on for
1.7, or is that too ambitious right now?
We probably could get to green on the interpreter and compiler by 1.7 and
we can definitely invite people to play with it and get us bug reports.
1. Getting to green: About 30 odd
On Sat, May 28, 2011 at 7:17 AM, Hirotsugu Asari asari.r...@gmail.comwrote:
Hello, I need some help on getting the snapshots built. (You might have
noticed that our last is 3 weeks old at http://ci.jruby.org/snapshots)
If you look at the last failure (
Hi Nahi,
Yes, 1.6 would sound promising :) but, you should talk with Tom and
Charlie about the current status of the new interpreter before you
make that change.
Regards,
Subbu.
On Wed, Aug 25, 2010 at 2:06 AM, Hiroshi Nakamura nakah...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hi Nahi,
As for the IR-based work, looks good to me. Components that will be
part of the new compiler are already in place. There is a framework
to run different analyses and optimization passes (eliminate
unnecessary frame loads stores, live variable analyses, dead code
elimination) as well as
I've filed a bug report for that:
http://jira.codehaus.org/browse/JRUBY-4263
Another possibility I was hoping to get some good results was to use
pre-compiled rb files into classes. But that turned out even worse
performance (10x worse or so):
-Beaver scanner-parser generator combination.
Subbu.
On Wed, Dec 2, 2009 at 10:52 AM, Thomas E Enebo tom.en...@gmail.com wrote:
On Wed, Dec 2, 2009 at 10:11 AM, Subramanya Sastry sss.li...@gmail.com
wrote:
I've filed a bug report for that:
http://jira.codehaus.org/browse/JRUBY-4263
Just a quick note so that I don't forget it.
Not sure how method lookup is implemented, but it occured to me that a
simple optimization might speedup lookup. This is not a big deal when
inline caching is implemented, but nevertheless something worth considering.
i.e. given a call o.foo(args),
to be honest, I forgot about hashing altogether .. embarassed smile :-) ...
but, might be good to think through / experiment a bit ... -s.
On Mon, Aug 10, 2009 at 10:07 AM, Thomas E Enebo tom.en...@gmail.comwrote:
On Mon, Aug 10, 2009 at 10:04 AM, Thomas E Enebotom.en...@gmail.com
wrote:
On Mon, Aug 10, 2009 at 11:16 AM, Ola Bini ola.b...@gmail.com wrote:
Ola Bini wrote:
I replaced our method tables with tries a few years back. The performance
ended up being quite bad since the trie implementation need to handle more
than just alphabetic characters, so each trie node needs
On Mon, Aug 10, 2009 at 12:06 PM, Ola Bini ola.b...@gmail.com wrote:
It is O(k) where k = length of lookup string. But, in practice, where the
set of strings that is being stored is a set of method names (mostly human
generated), you never hit the worst case.
Yeah, n was length of lookup
Charlie,
Let us discuss this when we meet up sometime later this week.
Subbu.
On Sat, Aug 1, 2009 at 9:46 AM, Charles Oliver Nutter
head...@headius.comwrote:
I tweaked the new IR compiler to support Duby's type declarations last
night. This is intended for Duby use, but if we ever thought
It is good to hear from everyone about common code patterns and what the
common scenarios are, and what needs to be targeted. But, the problem
often
is that ensuring correctness for the 1% (or even 0.1%) uncommon case
might
effectively block good performance for the 99% common case.
I have been trying to lay down clearly all the dynamic features of Ruby so
that I understand this better. Please add/correct if I have understood this
incorrectly
1. Open classes: This is the well known case where you can modify classes,
add methods, redefine methods at runtime. This
On Sat, Jul 25, 2009 at 11:49 AM, Yehuda Katz wyc...@gmail.com wrote:
It seems to me that *all* calls to dangerous methods are basically leaf
calls, because you only need to grab the frame information one frame above
where the information was added.
So you should be able to have each Ruby
Okay last mail for the day :-)
However--as I have pointed out to Charlie a number of times--in practice,
classes are basically frozen after *some* time. In Rails, pretty much all
classes reach their final stage at the end of the bootup phase. However,
since JRuby only sees a parse phase and
On Fri, Jul 24, 2009 at 9:34 AM, Ola Bini ola.b...@gmail.com wrote:
Subramanya Sastry wrote:
So, the real question here boils down to the previous one: can we safely
determine what local variables are captured by closures? In that sense,
this is not a new special case that we need
Consider this:
o.m1(..)
o.m2(..)
Since type of o hasn't changed between the 2 calls, you can skip the
method
table load for the second call.Anyway, I need to understand the call
protocol in greater detail to comment more.
This is an interesting use-case for closures. If
Obviously the IR already captures whether a closure accesses its own
variables or captured variables, right?
Implicitly yes. This information will become explicit after reaching defs /
live variable analysis is done to know whether the variables being access
live entirely within the closure
Assume a closure is implemented as follows:
class Closure {
public Scope s;// Enclosing scope
public Method meth;
Closure(Scope s, Method m) { ... }
public Object yield(Object[] args) { m.call(s, args); }
}
At a call site that takes a block, you
Here 'call' could be a regular C call for all you care. So, what would
happen in the compiler is that you would first transform the code into
a higher-level IR (with virtual calls as above), and at some point in the
optimization, you will ratchet down the IR one level lower that might
expose
39 matches
Mail list logo
