Re: Proposal: runtime-modifying Kernel methods should be keywords

Calamitas wrote:
> First off, let me say that I don't know how JRuby works internally.
> I'm looking at this problem from the point of view of a C
> implementation like Matz'. It's very possible that JRuby's
> architecture makes things more difficult for you. Having implemented a
> Prolog abstract machine on top of Java once, I know how difficult it
> is to write an interpreter for a language whose execution model is
> very different from Java. Ideally you want to match language
> constructs as much as possible, but once you need to explicitly code
> the nitty-gritty of completely unsupported language constructs, you're
> likely to end up with quite inefficient code because you have no low
> level control over the machine (like stack access and use of
> pointers), which is needed for many optimization techniques. In that
> regard, HotSpot, I believe, also has the advantage of sitting on top
> of the bare machine rather than on top of Java's virtual machine.

Ruby's execution model isn't all that much different from the JVM's with 
a few specific exceptions: closures having explicit access to the 
surrounding scope; no static classes or method signatures; no 
static-typed variables; and a few troublesome, sometimes undetectable 
methods that implicitly cross scoping and framing boundaries. Other than 
the last burden, none of these are particularly difficult to overcome, 
and indeed all of them have been overcome in JRuby's interpreted and 
compiled modes already. But there's much to be gained in making those 
troublesome methods either keywords or in some other way making their 
implicit behavior explicit and detectable.

Note I refer to the JVM here...the JVM is largely a different beast than 
Java. The JVM stack can accept any values, reference or primitive. Local 
variables are not typed unless explicitly told to do so, and can also 
accept both reference and primitive values. The places where Java leaks 
into what the JVM is are mostly related to representing methods and 
classes, where classes must be created in a single shot ahead of time 
and methods signatures and invocations must explicitly specify all 
types. The class restrictions and the static nature of method invocation 
are potentially going to be remedied in the upcoming JVM specification, 
and my work on JRuby's compiler will help prove out some of those changes.

> Your second alternative seems the least attractive. It puts the burden
> on the caller, and the overhead there will always be larger.
> 
> The deoptimization is pretty easy for a system like YARV. The
> bytecodes can be updated easily, and a scope can be created from the
> local variables provided that none were optimized away. This is a
> limitation for the HotSpot compiler too, so it seems to be only a
> minor problem.

I think you are theorizing about what might be possible in YARV rather 
than what is actually the case. Does YARV do this?

> Given that you are talking above about these methods containing twice
> as much code, I assume your current model is to generate pure Java
> code with lots of if-statements to detect the dynamic aspects of Ruby.
> If so, then your compiled model is quite differently from that of
> HotSpot and of YARV. In essence, they allow self-modifying code which
> is an important tool when you want to do dynamic deoptimization and
> such.

That is not our current model. And I would agree on your HotSpot point, 
but less so on the YARV point...I have not seen evidence to indicate 
YARV self-modifies code to make such optimizations. If that is actually 
the case, I'd love to hear more about it.

> I think we'll have to agree to disagree here. In Ruby performance has
> never been the first concern. Ruby does optimize in places, and

That doesn't mean performance shouldn't be improved or that people 
aren't interested in better performance. There are many of us who would 
gladly make this exchange (a few methods for keywords) because to us the 
benefits are great enough. I don't claim the change is for everyone, or 
that everyone would be happy with it...but I made this proposal to gauge 
that interest.

> advent of compilers for Ruby, I would like to see Matz move away from
> these "premature" optimizations that in my opinion are among the few
> blemishes on Ruby's blazon.

I would have no problems with a "more dynamic" Ruby if it were made 
explicitly so. The concern I have is the very few core methods with 
implicit requirements well outside the requirements of almost all other 
methods in the system.

> As for HotSpot needing time to get going, that's always so if you
> don't have a separate compilation phase. I don't know if JRuby does,
> but if it doesn't, I'm sure the generated code is cached. HotSpot
> could in theory do the same thing, but because the code that HotSpot
> generates can change over time, it will have to store a kind of
> initial compilation from which it can later on diverge if needed. For
> Ruby, I'm pretty sure something comparable can be done such that the
> first run of a program will be slower but subsequent runs will be
> faster. Eval'ed method definitions will always be a problem in that
> respect, but maybe something like ccache can be used there. Also note
> that although Ruby code can be extremely dynamic, in practice it isn't
> that dynamic, or there are patterns in the dynamic behavior that can
> be exploited such that the time needed for dynamic compilation is
> acceptable.

JRuby's current implementation is a mixed-mode execution environment 
similar to HotSpot. Unless compiled ahead of time (AOT compilation 
works, but is incomplete), all code runs in interpreted mode for some 
number of invocations. After that time, We generate Java bytecode for 
the methods. There is also a bit of information gathering during 
interpreted mode...more and more each day...that help us tailor the 
resulting compiled code to be more accurate. Also, in compiled mode, all 
call site optimizations are done via call adapters that can be either a 
generic implementation or generated pieces of code that can quickly and 
directly invoke the actual target code.

An idea does come to mind at this point...during interpretation, it 
would be possible to record at interpreted call sites what methods were 
*actually* being invoked, and thereby learn what calls were *most 
likely* to be invoked in the compiled code. These sorts of optimizations 
are not in place...partially because they are complicated to engineer 
and partially because currently the compiler is almost entirely a 
one-man show.

There aren't enough hours in the day.

> Sure, but you equate eval not being a keyword and performance begin
> crippled, and I don't think that you should. From my own experiences

I am equating incomplete knowledge about target methods (i.e. whether 
they--unlike 99% of methods in the system--require additional knowledge 
about the call stack and variable scopes) with performance being much 
more difficult to attain. I did not equate eval-as-method with 
explicitly poor performance, and this thread was not started to make 
such a claim. I'm merely pointing out that eval's behavior in light of 
typical method behavior is a difficult-to-detect aberration for 
questionable benefit. I have also stated that an alternative to making 
eval a keyword would be to require it to take a binding, and make 
binding a keyword...which is a less intrusive change and potentially an 
easier pill to swallow.

I'd like to hear about what runtime optimizations YARV is doing at 
present. Last time I spoke with Koichi, there were very few or none in 
place; all methods were treated as they are in Ruby 1.8 and statically 
compiled exactly once. There have also been multiple performance 
comparisons of YARV to Ruby 1.8, and while it does very well on standard 
method execution (the sorts we could optimize for) it has even poorer 
performance executing eval than Ruby 1.8. That's food for thought.

> I must say you have a very grim view on all this. I would rather see
> Ruby become even more dynamic, discarding some of the quirks that are
> there in the name of optimization. An optimizing compiler would allow
> moving those optimizations to the compiler, leaving more freedom for
> the programmer. Keywords limit freedom. For instance, return and yield
> could be methods, and if they are not overridden, the call overhead
> can be optimized away. In my opinion a compiler can open up
> possibilities.

I have a pragmatic view, as one trying to implement Ruby. It's easy to 
claim that the problem has many solutions when you aren't going through 
the pain of implementing them. Not that you don't have the knowledge or 
experience to be right, but I would like to complete this thing in my 
lifetime :)

- Charlie