Ok, the ricochet flag performs in the expected range...but still
slower than the old logic, and also slower than the 5/13 macosx build.
~/projects/jruby ➔ jruby -X+C
-J-Djava.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=false --server
bench/bench_fib_recursive.rb 5 35
9227465
1.354000 0.000000 1.354000 ( 1.249000)
9227465
0.962000 0.000000 0.962000 ( 0.962000)
9227465
0.953000 0.000000 0.953000 ( 0.953000)
9227465
0.953000 0.000000 0.953000 ( 0.954000)
9227465
0.958000 0.000000 0.958000 ( 0.958000)
~/projects/jruby ➔ jruby -X+C
-J-Djava.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=true --server
bench/bench_fib_recursive.rb 5 35
9227465
1.316000 0.000000 1.316000 ( 1.264000)
9227465
1.001000 0.000000 1.001000 ( 1.001000)
9227465
1.010000 0.000000 1.010000 ( 1.011000)
9227465
0.999000 0.000000 0.999000 ( 1.000000)
9227465
1.008000 0.000000 1.008000 ( 1.008000)
~/projects/jruby ➔ pickjdk 2
New JDK: 1.7.0.jdk
~/projects/jruby ➔ jruby -X+C --server bench/bench_fib_recursive.rb 5 359227465
1.127000 0.000000 1.127000 ( 0.940000)
9227465
0.810000 0.000000 0.810000 ( 0.810000)
9227465
0.809000 0.000000 0.809000 ( 0.809000)
9227465
0.810000 0.000000 0.810000 ( 0.810000)
9227465
0.822000 0.000000 0.822000 ( 0.822000)
The last result is the 5/13 build.
Another angle: fib with Float (a boxed double, basically):
~/projects/jruby ➔ jruby -X+C
-J-Djava.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=true --server
bench/bench_fib_float_recursive.rb 5 35
9227465.0
2.492000 0.000000 2.492000 ( 2.437000)
9227465.0
1.951000 0.000000 1.951000 ( 1.951000)
9227465.0
1.950000 0.000000 1.950000 ( 1.950000)
9227465.0
1.951000 0.000000 1.951000 ( 1.952000)
^C
~/projects/jruby ➔ jruby -X+C
-J-Djava.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=false --server
bench/bench_fib_float_recursive.rb 5 35
9227465.0
2.369000 0.000000 2.369000 ( 2.324000)
9227465.0
1.916000 0.000000 1.916000 ( 1.916000)
9227465.0
1.904000 0.000000 1.904000 ( 1.904000)
9227465.0
1.905000 0.000000 1.905000 ( 1.905000)
9227465.0
1.924000 0.000000 1.924000 ( 1.924000)
~/projects/jruby ➔ pickjdk 2New JDK: 1.7.0.jdk
~/projects/jruby ➔ jruby -X+C --server
bench/bench_fib_float_recursive.rb 5 359227465.0
2.110000 0.000000 2.110000 ( 2.055000)
9227465.0
1.690000 0.000000 1.690000 ( 1.690000)
9227465.0
1.718000 0.000000 1.718000 ( 1.718000)
9227465.0
1.721000 0.000000 1.721000 ( 1.721000)
I'm on leave right now so I can't spend a lot of time investigating
this until perhaps Monday.
- Charlie
On Thu, Jun 2, 2011 at 10:23 AM, Charles Oliver Nutter
<head...@headius.com> wrote:
> I tentatively admit guilt. I was still running off the 5/26 build,
> which still had convertArguments and probably didn't have all the
> recent optimizations for ricochet. I'm doing an updated build now and
> will report back shortly.
>
> On Thu, Jun 2, 2011 at 10:13 AM, Charles Oliver Nutter
> <head...@headius.com> wrote:
>> Ok, I'll reinvestigate; I thought I had logged that it was compiling
>> but perhaps that wasn't with the new property...
>>
>> On Wed, Jun 1, 2011 at 3:37 PM, Tom Rodriguez <tom.rodrig...@oracle.com>
>> wrote:
>>> I'm seeing slow perf as well but I think it might be a jruby/292 mismatch
>>> problem:
>>>
>>> Exception <a 'java/lang/NoSuchMethodError'>:
>>> java.lang.invoke.MethodHandles.convertArguments(Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodT\
>>> ype;)Ljava/lang/invoke/MethodHandle; (0xefdd4b18 )
>>> thrown
>>> [/net/smite.us.oracle.com/export/ws/bim/src/share/vm/interpreter/linkResolver.cpp,
>>> line 354]
>>> for thread 0x0807c800
>>> Exception <a 'java/lang/NoSuchMethodError'> (0xefdd4b18)
>>> thrown in interpreter method <{method} '<clinit>' '()V' in
>>> 'org/jruby/runtime/invokedynamic/InvokeDynamicSupport'>
>>> at bci 2876 for thread 0x0807c800
>>> Exception <a 'java/lang/NoSuchMethodError'> (0xefdd4b18 )
>>>
>>> which results in this:
>>>
>>> Exception <a 'java/lang/NoSuchMethodError'> (0xefdd4b18)
>>> thrown in interpreter method <{method} 'tryCompile'
>>> '(Lorg/jruby/ast/Node;Ljava/lang/String;Lorg/jruby/util/JRubyClassLoader;Lorg>
>>> at bci 56 for thread 0x0807c800
>>> Exception <a 'java/lang/NoClassDefFoundError'>: Could not initialize class
>>> org.jruby.compiler.impl.StandardASMCompiler (0xefe4c818 )
>>> thrown
>>> [/net/smite.us.oracle.com/export/ws/bim/src/share/vm/oops/instanceKlass.cpp,
>>> line 440]
>>> for thread 0x0807c800
>>> Exception <a 'java/lang/NoClassDefFoundError'> (0xefe4c818)
>>> thrown in interpreter method <{method} '<init>'
>>> '(Ljava/lang/String;Ljava/lang/String;Lorg/jruby/Ruby;Lorg/jruby/internal/runtime>
>>> at bci 126 for thread 0x0807c800
>>> Exception <a 'java/lang/NoClassDefFoundError'> (0xefe4c818)
>>> thrown in interpreter method <{method} 'jitThresholdReached'
>>> '(Lorg/jruby/internal/runtime/methods/DefaultMethod;Lorg/jruby/RubyI>
>>> at bci 220 for thread 0x0807c800
>>>
>>> So I think the jruby compiler never triggers with the new meth.jar.
>>>
>>> tom
>>>
>>> On May 31, 2011, at 12:03 PM, John Rose wrote:
>>>
>>>> On May 31, 2011, at 9:36 AM, Charles Oliver Nutter wrote:
>>>>
>>>>> If you mean java.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=true, then I
>>>>> have more bad news...it's even slower :(
>>>>
>>>> Is that with meth-bim.patch applied? That is Tom's first cut at an
>>>> optimization for RFs.
>>>>
>>>> -- John
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev@openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
