Blog: November 30, 2009: Why Object-Oriented Languages Need Tail. [Note: The original blog post used the term "tail-recursion", but in response to feedback on December 1, I have replaced this term with "tail calls" to emphasize that the issue has to do with multiple objects calling each others' methods, not just the limited case of an object invoking its own methods or the even more limited case of a single method invoking itself (whether on the same object or another object). Also, some minor errors in the code examples have been corrected as of December 3.] We recommend an interesting essay from the recent ACM OOPSLA Conference: William R. Cook. On understanding data abstraction, revisited. Cook makes an important distinction between abstract data types and object-oriented programming , and argues that they have related but complementary characteristics.
Following Cook, we begin by considering an abstraction of "sets of integer values". But we digress.) One possible implementation for the original API is as follows: J is for JVM: Why the ‘J’ in JRuby? The current JRuby team members are all passionate hackers with intimate knowledge of Ruby, Java, and of course JRuby.
That said, none of us were on the team at the project's original inception. I assume the JRuby pioneers thought JRuby would be a good idea—I know I did, when I first heard about it. For a lot of folks though, it's somewhat less obvious. Why is writing JRuby on top of the JVM a good idea, they ask. Are we nuts, evil geniuses, or is using the JVM just a solid pragmatic decision? When Java first came out it was a nice incremental improvement over languages at the time. In an attempt to market Java as a simple single-named entity, though, I think Sun made a long-term marketing mistake.
This post will focus on the good and the bad of the JVM, and by the end of this entry, I'm hoping you'll appreciate all the JVM has to offer. One final note before I delve further: this will just cover what I know about Sun's JVM. The Bad No technology is perfect. JRuby's New IR Paves the Way for Future Performance Improve. JRuby has made great progress with regards to performance.
A year ago, JRuby was the fastest implementation for Ruby 1.8 code. JRuby performance has been raised with every release, and further improvements are on the horizon with the new intermediate representation (IR) that is beeing developed by Subbu Sastry. InfoQ talked to Subbu to learn how this new IR looks and what benefits it will bring to JRuby. Before talking about the new intermediate representation, how does the compiler currently do its work without the IR?
Strictly speaking, the AST (abstract syntax tree) is also an IR (intermediate representation) – since it is not quite the source, and not quite the target language. (The JRuby AST is the output of the parser and is just a tree representation of the source code, containing different kinds of nodes, for example for classes, methods, variables. Tom Enebo adds that "the JIT threshold is just a method invocation counter. -J-D jruby.jit.threshold=<invocation count> Jvm languages performance. On Tue, Nov 17, 2009 at 6:48 AM, Rich Hickey <richh...
@gmail.com> wrote: > I think it is essential to separate the *two* problems with boxed > numbers. One problem is arithmetic with boxed numbers. EA, inlining, > lever compilers etc can certainly do something about this. Frederik > Öhrström gave an impressive demonstration at the JVM language summit > showing how even large structures used as numbers could provide > sufficient information to the compiler to enable their complete > removal in arithmetic. And I have seen, for very limited cases, that some boxed numerics are eliminated in the final assembly. Because of this I've resigned myself that without JVM help we're not going to be able to compete with other Ruby implementations on raw numeric performance, since all the C/C++ based Ruby impls use real fixnums. > The second, significant, and currently unavoidable problem with > objects as numbers is that they do, in fact, escape.
This is one I have worried about. . - Charlie.