Charles Oliver Nutter wrote:
Quickly before I get on my flight...let me know what y'all think of this.
- 1.1.x development will proceed on trunk for a while, so 1.1.1 will
include everything that's been fixed on trunk. Barring major rework or
rewrites, I think there's a lot of fixes we can make during 1.1
maintenance cycle before we branch it and it starts to rot (or we have
to constantly merge fixes over).
- We need to consider what version number we might want for
JRuby.next...1.2? 2.0? Tom suggested 3.0 since it wouldn't confuse
people about JRuby 2.0/Ruby 2.0. I think it's open for discussion.
- There are at least two major areas we'll want to start preparing for
in the JRuby.next cycle: Java integration (performance, efficiency,
and perhaps lightweight/Object support throughout JRuby), and Ruby 1.9
feature support (to whatever extent is appropriate, since Ruby 1.9.x
is still a moving target). As always there will be continuing
performance and compatibility work, but I think these are the two
major new areas of development for the .next cycle.
A few personal goals as well:
- I'd like for us to clearly perform better on 1.9's benchmarks soon.
I think it's possible by putting in similar cheats, but in a way that
doesn't break 1.8 compatibility.
- I want to clean up and unify the entire call path logic so
everything is using the same annotation-based binding mechanism.
There's still a lot of code using callbacks, and block dispatch is
still 100% array-boxed. We could potentially get a big performance
boost from both callback-based methods and blocks if we get then using
specific-arity call paths.
- We need a way to make AOT and JIT-compiled methods support
specific-arity call paths. This could possibly use the annotation
binding logic as well. Also, we need a more efficient call path for
JIT-compiled methods, since they currently just get stuffed inside
DefaultMethod which has its own perf/efficiency concerns.
- I'd like to see us revisit rubinius support once Evan's new VM
lands. I think their opcode list at least has stabilized, and while
the list of primitives has grown extremely long I don't expect it
would be hard to implement them. I'd really like to have a rubinius VM
impl on JVM within the next several months.
Please add to this thread with large areas you think need attention
(and we're always looking for help making things go).
Good goals. I still believe that focused performance work on Rails is
still very much needed.
Cheers
--
Ola Bini (http://ola-bini.blogspot.com)
JRuby Core Developer
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
