Priorities for JRuby 1.3

[Charles Oliver Nutter]

With JRuby 1.2 almost out the door, we should talk a bit about where to
go with JRuby 1.3. There's always more work to do, but in this case
there's a few directions we could probably go.

Some obvious items will continue to see work:

* 1.9 libraries, interp, compiler, parser
* 1.8.6 bugs

But there's others that we may need to prioritize:

* 1.8.7 support
* Ruby execution performance (how fast do you want it?)
* Specific library performance (YAML, IO, Java)
* More Java integration refactoring (esp. subclassing)
* "Compiler #2" to produce normal Java classes from Ruby
* Improvements to AOT compilation (all-at-once, eliminate runtime codegen)

And there's a number of internal chores to work on too:

* Start generating most of the call path, to reduce duplicate code
* Specific-arity optimizations for block yield (could be big)
* Compiler cleanup and refactoring
* Modularization of core classes that aren't valid on applet, Android,
secured envs, etc; also may allow shipping smaller runtimes
* More startup perf work; I have a few ideas

As always, there's way more tasks than the few of us committing to JRuby
can work on, so I think we need to hear from users what's important. Any
of these? Other items?

- Charlie

 

[James Britt]

But there's others that we may need to prioritize:

* 1.8.7 support

Skip it.

* Ruby execution performance (how fast do you want it?)

Silly question. REALLY fast.

* Specific library performance (YAML, IO, Java)
* More Java integration refactoring (esp. subclassing)
* "Compiler #2" to produce normal Java classes from Ruby

That could be quite interesting.

* Modularization of core classes that aren't valid on applet, Android,
secured envs, etc; also may allow shipping smaller runtimes

Yes to more Android support (so to speak).


--
James Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

 

[M. Edward (Ed) Borasky]

Skip it.
+100


Silly question. =C2=A0REALLY fast.

See my posts on the Ruby Benchmark Suite list for that. But yeah ...
subject to the usual computer science tradeoffs between memory and
processor usage, as fast as you can get it for the core interpreter.

That could be quite interesting.

Well ... how about tuning the core engine for Rails / Merb and RSpec,
rather than singling out some lower-level libraries?

Yes to more Android support (so to speak).

There was a bit of applause here last week when I told the local
Tweeple about the Android port. And it put the final nail in the
coffin of every other "smart phone" I'd consider buying, although I
probably wouldn't buy an Android either. I'm not really interested in
a phone I can / have to program, when I can get a really nice headset
and Skype for my laptop.
--=20
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

 

[James Britt]

Well ... how about tuning the core engine for Rails / Merb and RSpec,

That's insane.

There's lots going on in Rubyland, and tuning the core engine for any
set of apps is evil.


--
James Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

 

[Charles Oliver Nutter]

That's insane.

There's lots going on in Rubyland, and tuning the core engine for any
set of apps is evil.

My answer to tuning for either Rails or Merb is basically that it means
tuning *everything* anyway. The reason JRuby has only recently started
to post convincingly better numbers on Rails/Merb is because they're not
Ruby execution-bound, they're solidly library-bound. So it's not how
fast we can execute code, it's how optimized String or Array or Hash
are. And that takes a lot longer.

I asked about execution performance because it's actually "easy" now for
me to make Ruby execution as fast as anyone wants (I've got prototype
code that's only a couple times slower than Java), but it has less and
less impact on application performance. When Ruby execution perf is only
10% of an app's run time, improving it 100-fold doesn't change a thing.

- Charlie

 

[Charles Oliver Nutter]

+100

That's been our general impression too...but I'll keep asking until
people start wanting it. So far, there's been nearly zero demand.

See my posts on the Ruby Benchmark Suite list for that. But yeah ...
subject to the usual computer science tradeoffs between memory and
processor usage, as fast as you can get it for the core interpreter.

I guess my actual question was "to what extent should we focus on Ruby
execution performance over other things?" given that we could endlessly
optimize execution for less and less gain. There's only so many hours in
the day...what portion of them should focus on execution perf and what
portion on tighter, cleaner integration with Java libraries?

There was a bit of applause here last week when I told the local
Tweeple about the Android port. And it put the final nail in the
coffin of every other "smart phone" I'd consider buying, although I
probably wouldn't buy an Android either. I'm not really interested in
a phone I can / have to program, when I can get a really nice headset
and Skype for my laptop.

I'm very excited about both the Android and CDC work, since it shows
that the core of JRuby can really scale to lots of different use cases.
I'm probably going to take a step back from both areas and let them
"simmer" in the community a bit while we close out 1.2 and ramp up 1.3,
but I've got big plans for both.

I've got a G1 on the way...now I just need to scam a Blu-Ray dev kit to
start working on "Bluby" with JRuby as the logic for apps.

- Charlie

 

[Robert Dober]

Charles Oliver Nutter wrote:

Silly question. =A0REALLY fast.

I am sure you can do better than that, maybe r i d i c o l o u s s p e e =
d?

R.
--=20
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

 

[Rados³aw Bu³at]

* Ruby execution performance (how fast do you want it?)

JRuby is very fast in micro benchmark but it doesn't run so well rails
(at least last time I checked it). Maybe you can investigate more what
hangs jruby in rails from running at the same level as jruby vs MRI
1.8 in micro benchmark?


--=20
Pozdrawiam

Rados=B3aw Bu=B3at
http://radarek.jogger.pl - m=F3j blog

 

[Ken Bloom]

With JRuby 1.2 almost out the door, we should talk a bit about where to
go with JRuby 1.3. There's always more work to do, but in this case
there's a few directions we could probably go.

Some obvious items will continue to see work:

* 1.9 libraries, interp, compiler, parser * 1.8.6 bugs

But there's others that we may need to prioritize:

* 1.8.7 support

I use Debian, who included 1.8.7 in their recent stable release, so most
of my code is being targeted to 1.8.7 these days. While I understand (and
agree with) philosophically the argument against making 1.8.7 to begin
with, once it's out and once it's the default on my platform, then that's
what I'm targeting.

If you're doing 1.9 libraries anyway, then I imagine it's relatively easy
to create a 1.8.7 compatibility mode by shaking up the list of what
methods are included in what classes under what circumstances. Right? If
so, then do it. (I imagine it wouldn't kill the 1.8.6 compatibility mode,
right?)

If it's really hard, and I'm the only voice talking, then maybe it's not
worth your effort. I'm not using JRuby a whole lot now as it is.

* "Compiler #2" to produce normal Java classes from Ruby

This would be really cool. I had been using Groovy for this purpose some
time ago, but ran away because it was slow (a problem that has since been
mostly solved) and has confusing semantics (a problem that may never be
fixed, since GPath seems to be their major selling point)

* Improvements to AOT compilation (all-at-once, eliminate runtime codegen)

I'm not sure what you have in mind here.

 

[John Wells]

[Note: parts of this message were removed to make it a legal post.]

On Sat, Feb 28, 2009 at 4:16 PM, Charles Oliver Nutter <

* More Java integration refactoring (esp. subclassing)
* "Compiler #2" to produce normal Java classes from Ruby

My vote is for these two...better Java integration would mean my company
could take our current three language environment (java, ruby and groovy) to
two...

John

 

[Charles Oliver Nutter]

JRuby is very fast in micro benchmark but it doesn't run so well rails
(at least last time I checked it). Maybe you can investigate more what
hangs jruby in rails from running at the same level as jruby vs MRI
1.8 in micro benchmark?

I'm hopeful that we've solved that. There are lingering issues that keep
AR from being faster than MRI (a major one is the lack of unix sockets
for JDBC, which does help keep MRI ahead), but for some internal
benchmarks we've run we're finally looking like 10-20% faster for most
things. And of course as applications get more complex and have more
user code, we pull away due to faster core classes and execution speed.

But of course we're interested in user stories to know where to focus
Rails-related perf work in the future.

- Charlie

 

[Charles Oliver Nutter]

I use Debian, who included 1.8.7 in their recent stable release, so most
of my code is being targeted to 1.8.7 these days. While I understand (and
agree with) philosophically the argument against making 1.8.7 to begin
with, once it's out and once it's the default on my platform, then that's
what I'm targeting.

If you're doing 1.9 libraries anyway, then I imagine it's relatively easy
to create a 1.8.7 compatibility mode by shaking up the list of what
methods are included in what classes under what circumstances. Right? If
so, then do it. (I imagine it wouldn't kill the 1.8.6 compatibility mode,
right?)

If it's really hard, and I'm the only voice talking, then maybe it's not

Well, here's the deal. You're right that a lot of the work *may* already
be there, and maybe just needs to be rewired. The biggest thing that
keeps me personally from wanting to support 1.8.7 is a lack of RubySpecs
for the new and modified features. Anyone interested in 1.8.7 support in
JRuby should register their vote by contributing 1.8.7 feature specs.

* "Compiler #2" to produce normal Java classes from Ruby

This would be really cool. I had been using Groovy for this purpose some
time ago, but ran away because it was slow (a problem that has since been
mostly solved) and has confusing semantics (a problem that may never be
fixed, since GPath seems to be their major selling point)

Yeah, I have a general idea how it will work in my head, and it's always
been doable. I had to open my big mouth and offer it as a 1.3
feature...just about everyone has asked for it now.

* Improvements to AOT compilation (all-at-once, eliminate runtime codegen)

I'm not sure what you have in mind here.

Currently when you AOT compile Ruby code, there's still some code
generated at runtime. This means you can't AOT compile to put on a
mobile device or in an unsigned applet, and you're force to interpret in
those cases. This work would make AOT compilation more "complete", doing
that additional bit of code generation at the same time.

- Charlie

 

[Charles Oliver Nutter]

My vote is for these two...better Java integration would mean my company
could take our current three language environment (java, ruby and groovy) to
two...

Well, that's certainly motivation for us

- Charlie

 

[Chauk-Mean Proum]

Hi,

With JRuby 1.2 almost out the door, we should talk a bit about where to
go with JRuby 1.3. There's always more work to do, but in this case
there's a few directions we could probably go.

* More Java integration with Ruby style :

http://jira.codehaus.org/browse/JRUBY-3443

* And what about win32ole support in JRuby ?

I really miss this support in order to automate Windows application.
I currently use MRI for this task.

Cheers.

Chauk-Mean.

 

[Thomas Enebo]

Hi,


* More Java integration with Ruby style :

http://jira.codehaus.org/browse/JRUBY-3443

* And what about win32ole support in JRuby ?

I really miss this support in order to automate Windows application.
I currently use MRI for this task.

Cheers.

Chauk-Mean.

I made something which uses the Jacob library which seems to be mildly
compatible with win32ole (I had a script I had written against win32ole
and it continued to work with JRuby). I will do a quick stab at
landing something really really preliminary for JRuby 1.3. We can
figure out what is missing at that point and probably start trying to
support this library in more earnest.

-Tom

 

[Thomas Enebo]

On Sat, Feb 28, 2009 at 4:16 PM, Charles Oliver Nutter <


My vote is for these two...better Java integration would mean my company
could take our current three language environment (java, ruby and groovy) to
two...

John

Can I ask which specific features of Java integration are holding you
back? For example, are you missing annotation support? We have
talked about compiler #2 for a long time, now but it would be cool to
get better real-world use-cases...

-Tom

 

[Chauk-Mean Proum]

I made something which uses the Jacob library which seems to be mildly
compatible with win32ole (I had a script I had written against win32ole
and it continued to work with JRuby). I will do a quick stab at
landing something really really preliminary for JRuby 1.3. We can
figure out what is missing at that point and probably start trying to
support this library in more earnest.

That's a very good news.

Cheers.

Chauk-Mean.