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).
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
