JRuby can't compile benchmark. Also package renaming

[Charles Oliver Nutter]

Ok, running off jsr292-mock 1.6 and a prerelease build of ASM 4.0
(thanks Rémi for your help) I have pushed an updated branch that's all
java.lang.invoke, new bootstrap style, and properly compiling and
loading code.

https://github.com/jruby/jruby/tree/indy_update

The compile failure was because I was still emitting bytecode version
as 1.6 and Hotspot had started rejecting it when it contained
invokedynamic. Minor fix.

Kirill: You should be able to pull and build this branch with recent
Java 7 builds and it should work fine.

I have some good news and bad news.

The good: As of this update and using Stephen's recent build,
invokedynamic-based dispatch is now a good 30% faster on
bench_fib_recursive.rb than JRuby's caching call site dispatch. Even
better, it is now only about 20% slower than my "dynopt" compilation,
which is essentially doing all direct, static/virtual calls. I'm super
excited about this! This also marks the first time that invokedynamic
has come in faster than other optimizing Ruby impls...and those impls
use tagged pointers for Fixnum (instead of our big fat RubyFixnum
object), so it's an amazing win.

The bad: I still have to bump the inlining budgets *way* up. I'm using
MaxInlineSize=150 and InlineSmallCode=5000 to get these great numbers.
Without those set, invokedynamic is 5x slower than CachingCallSite and
10x slower than dynopt. Somethin's gotta give, man!

Awesome stuff, regardless. I'll merge this to JRuby master once ASM 4 is out.

- Charlie

On Wed, Apr 6, 2011 at 11:45 AM, John Rose <john.r.rose at oracle.com> wrote:
> On Apr 6, 2011, at 9:35 AM, Charles Oliver Nutter wrote:
>
> And the flag does not seem to work either :(
>
> [apt] Warning: The flag +AllowTransitionalJSR292 has been EOL'd as of
> 7.0 and will be ignored
>
> There might be ways you could combine a previous build with an even older
> meth.jar (containing Linkage) plus +AllowTransitionalJSR292.  But it's
> probably better to forge ahead.
> Thanks, Remi, for the rapid response.
> -- John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>