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 const
On Thu, Feb 6, 2014 at 6:49 PM, Subramanya Sastry wrote:
>
>
>
> On Thu, Feb 6, 2014 at 5:46 PM, Charles Oliver Nutter > wrote:
>
> I also ran into an issue with how heap variable assignment is being
>> optimized:
>>
>> for the closure passed to f
On Thu, Feb 6, 2014 at 5:46 PM, Charles Oliver Nutter
wrote:
> 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 ready to go.
> I a
> 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 == B
On Fri, Jan 31, 2014 at 5:56 AM, Charles Oliver Nutter
wrote:
> 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 the following
fixes.
Subbu.
On Sun, Jan 26, 2014 at 9:22 AM, Subramanya Sastry wrote:
>
>
>
>
> 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 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
On Tue, Oct 1, 2013 at 4:20 PM, Charles Oliver Nutter
wrote:
> Many questions!
>
> On Tue, Oct 1, 2013 at 3:41 PM, Jon Zeppieri wrote:
> > - Are NotCompilableExceptions caught somewhere, allowing the
> > interpreter to carry on? (I did a simple grep for this, but didn't
> > find it.) Or was that
FYI. This commit also fixes JRUBY-6705.
--
commit 7c3f6426eb26e560f21b2f1905923fa624c4408c
Author: Subramanya Sastry
Date: Thu Jun 21 23:43:39 2012 -0500
HEADS UP! Removed all trace of setWithinDefined and isWithinDefined.
* Tested on rubyspecs in 1.8 and 1.9 mode -- AST
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)
the JVM to
> inline through to closures).
>
> - Charlie
>
> On Tue, May 8, 2012 at 2:14 AM, Charles Oliver Nutter
> wrote:
> > I will look into this a bit tonight and see if I can get basic binding
> > logic implemented in IR2JVM. Thanks, Subbu!
> >
> > O
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 a
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 run
ch is worth investigating to see how far it can be
pushed.
Subbu.
On Fri, May 4, 2012 at 12:39 AM, Charles Oliver Nutter
wrote:
> On Fri, May 4, 2012 at 6:27 AM, Subramanya Sastry
> wrote:
> > I was making my case on the assumption that access to $~ is always
> through
> > Ruby code, a
> > So, we create LastMatch, and get rid of Backref and NthRef operands and
> > convert them into special calls on the LastMatch operand.
> >
> > And, here are the two significant changes. If there are no uses of
> > LastMatch in a method (and all descendent scopes -- blocks passed into
> > calls)
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
fu
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/
Subbu
* 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,
ubject: A bit more IR2JVM work on the flight home
> --------
>
> From: *Charles Oliver Nutter*
> Date: Sun, Apr 22, 2012 at 8:58 PM
> To: Subramanya Sastry , Thomas Enebo <
> tom.en...@gmail.com>
>
>
> https://gist.github.com/2466877
>
> Good old
Awesome! -Subbu.
On Tue, Dec 6, 2011 at 7:44 AM, Charles Oliver Nutter
wrote:
> 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 github.com/rubyspe
> * 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 s
On Sat, May 28, 2011 at 7:17 AM, Hirotsugu Asari wrote:
> 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 (
> http://ci.jruby.org/job/jruby-dist/lastFailedBuild/cons
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 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Sub
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
JFlex-Beaver scanner-parser generator combination.
Subbu.
On Wed, Dec 2, 2009 at 10:52 AM, Thomas E Enebo wrote:
> On Wed, Dec 2, 2009 at 10:11 AM, Subramanya Sastry
> wrote:
> >
> >> > I've filed a bug report for that:
> >> > http://jira.codeha
> > 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):
> >
> > http://jira.codehaus.org/
On Mon, Aug 10, 2009 at 12:06 PM, Ola Bini 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 string i
On Mon, Aug 10, 2009 at 11:16 AM, Ola Bini 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 to have an i
t; Speeding up lookup will not affect anything which has an inline cache,
> > but we have many internal calls without any inline caches. So this
> > could help that OR we could try and come up with a way of adding
> > inline caches for those sites...
> >
> > -Tom
> >
&g
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)",
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
wrote:
> 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 the
> politics of ty
Here is one possibility for optimistic optimizations of ruby code in the
presence of open classes without on-stack replacement (OSR).
To see this, it is useful to think of all ruby classes carrying with them a
version number. [ Technically, this can be done at a more fine-grained
level (i.e. at t
> > 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
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 Sat, Jul 25, 2009 at 11:49 AM, Yehuda Katz 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 *thread* all
But there is a way out of this. Yehuda and I talked a bit about it and
> realized that if we could inspect the target method whenever we're
> calling a block, we could determine whether a full heap scope would be
> needed. There are only three constructs that would trigger this
> potential:
>
> * A
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 effectively
On Fri, Jul 24, 2009 at 9:34 AM, Ola Bini 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 n
> >
> > 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
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 bo
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 hav
> 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
>
This note interweaves code optimization with discussion about IR because
the IR choice will be influenced by what you want to do with it. I am
going to use examples below to guide this discussion. A lot of it is
somewhat 'stream-of-thought' writing -- this is not a tight spec.
Since we let HotSp
43 matches
Mail list logo
