On Thu, Dec 1, 2011 at 9:47 AM, Stephen Bannasch
wrote:
> At 3:29 AM -0600 12/1/11, Charles Oliver Nutter wrote:
>>This is a pretty disappointing finding. I'm not yet sure whether it's
>>a bug in SwitchPoint optimization or in JRuby's use of SwitchPoint,
>>but I'd like to see your numbers with and
At 3:29 AM -0600 12/1/11, Charles Oliver Nutter wrote:
>This is a pretty disappointing finding. I'm not yet sure whether it's
>a bug in SwitchPoint optimization or in JRuby's use of SwitchPoint,
>but I'd like to see your numbers with and without this flag.
Latest JRuby master, on Java 1.6.0_27, ma
On Thu, Dec 1, 2011 at 2:23 AM, Charles Oliver Nutter
wrote:
> I am still seeing rebinding in profiles of some of the remaining slow
> benchmarks, so I'm missing something.
Bleah, I seem to have found the problem.
If I disable the use of SwitchPoint for class-mutation-originated call
site invali
On Wed, Nov 30, 2011 at 9:52 PM, Stephen Bannasch
wrote:
> At 3:03 PM -0500 11/30/11, Stephen Bannasch wrote:
>>Benchmark code here: https://gist.github.com/1410423
>
> The hpricot benchmark is also slowed down consdierably.
I have found more issues in my invokedynamic binding logic and am in
the
At 5:25 PM -0600 11/30/11, Charles Oliver Nutter wrote:
>On Wed, Nov 30, 2011 at 3:27 PM, Stephen Bannasch
> wrote:
>> user system totalreal
>> rexml 73.54 0.00 73.54 ( 73.54)
>> hpricot 6.483000 0.
I may have found one big problem, using some rexml benchmarks I found.
The instance-variable logic I just added seems like it might not be
working right. It was supposed to be experimental and turned off, but
I used the wrong flag.
Invokedynamic disabled (-Xcompile.invokedynamic=false)
Parsing sm
On Wed, Nov 30, 2011 at 3:27 PM, Stephen Bannasch
wrote:
> user system total real
> rexml 73.54 0.00 73.54 ( 73.54)
> hpricot 6.483000 0.00 6.483000 ( 6.483000)
> jdom_document_builder 0.2
At 2:43 PM -0600 11/30/11, Charles Oliver Nutter wrote:
>I should add that if you're running this against a u2ish build and
>seeing poor performance, we need to talk. I'm not seeing that locally,
>and you shouldn't see it either.
Here's what I am testing with: Java 1.6.0_27 and macosx-port and mlv
I should add that if you're running this against a u2ish build and
seeing poor performance, we need to talk. I'm not seeing that locally,
and you shouldn't see it either.
- Charlie
On Wed, Nov 30, 2011 at 2:42 PM, Charles Oliver Nutter
wrote:
> On Wed, Nov 30, 2011 at 2:03 PM, Stephen Bannasch
>
On Wed, Nov 30, 2011 at 2:03 PM, Stephen Bannasch
wrote:
> Hi Charlie,
>
> Is your latest work going on in the indy_update branch?
No, that's old stuff. I should wipe it out. I can explain your perf
issue below, though.
> I have a simple Ruby xml processing benchmark that compares several Ruby X
Hi Charlie,
Is your latest work going on in the indy_update branch?
I have a simple Ruby xml processing benchmark that compares several Ruby XML
libraries including rexml which is part of the
Ruby standard library.
My test measures the time to do the following 100 times:
- open 98k XML docume
Hello friends!
Just updating you on the status of JRuby + invokedynamic, for those of
you following along.
About halfway through this month I did another pass at getting tests
passing with invokedynamic enabled, and finally turned on all uses (at
the time) of indy in JRuby! Hooray!
Last week, I
On Wed, Aug 24, 2011 at 8:50 AM, Christian Thalinger
wrote:
> I have some preliminary results for:
>
> 7079673: JSR 292: C1 should inline bytecoded method handle adapters
>
> These numbers are with:
>
> 7078382: JSR 292: don't count method handle adapters against inlining budgets
>
> applied (whic
On Aug 16, 2011, at 12:19 AM, Charles Oliver Nutter wrote:
> On Mon, Aug 15, 2011 at 1:01 PM, Tom Rodriguez
> wrote:
>>
>> On Aug 12, 2011, at 4:15 PM, Charles Oliver Nutter wrote:
>>> Well, let me play devil's advocate here: why not just discount MH
>>> chains completely?
>>
>> It really onl
On Aug 12, 2011, at 8:41 PM, Christian Thalinger wrote:
>
> On Aug 12, 2011, at 8:18 PM, Tom Rodriguez wrote:
>
>>> Well, it's the good old:
>>>
>>> @ 95 java.lang.invoke.MethodHandle::invokeExact (45 bytes) size >
>>> DesiredMethodLimit
>>>
>>> This seems to be the last recursive call t
On Aug 15, 2011, at 3:19 PM, Charles Oliver Nutter wrote:
> On Mon, Aug 15, 2011 at 1:01 PM, Tom Rodriguez
> wrote:
>>
>> On Aug 12, 2011, at 4:15 PM, Charles Oliver Nutter wrote:
>>> Well, let me play devil's advocate here: why not just discount MH
>>> chains completely?
>>
>> It really only
This is an auto-replied message. I am out of the office until Aug 22nd with
limited access to email and phone.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
This is an auto-replied message. I am out of the office until Aug 22nd with
limited access to email and phone.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
On Mon, Aug 15, 2011 at 1:01 PM, Tom Rodriguez wrote:
>
> On Aug 12, 2011, at 4:15 PM, Charles Oliver Nutter wrote:
>> Well, let me play devil's advocate here: why not just discount MH
>> chains completely?
>
> It really only to deal with pathologically long chains. Most method handle
> chains a
On Aug 12, 2011, at 4:15 PM, Charles Oliver Nutter wrote:
> On Fri, Aug 12, 2011 at 1:18 PM, Tom Rodriguez
> wrote:
>> I wonder if we need to be slightly more selective than this. Most method
>> handle chains are relatively small and we shouldn't be penalized for that
>> but they could be ar
On Fri, Aug 12, 2011 at 4:44 AM, Christian Thalinger
wrote:
> Well, it's the good old:
>
> @ 95 java.lang.invoke.MethodHandle::invokeExact (45 bytes) size >
> DesiredMethodLimit
>
> This seems to be the last recursive call that doesn't get inlined. Setting
> MaxRecursiveInlineLevel=0 makes
On Fri, Aug 12, 2011 at 1:18 PM, Tom Rodriguez wrote:
> I wonder if we need to be slightly more selective than this. Most method
> handle chains are relatively small and we shouldn't be penalized for that but
> they could be arbitrarily large too. Worst case they just expand into a
> bunch of
On 08/12/2011 08:22 PM, Tom Rodriguez wrote:
>> I wonder if this patch is not too much.
>> If a big method is called through an invokedynamic + method handle
>> then it will be inlined.
> That's not how it works. The methods called by the adapter will still have
> to pass normal inlining checks
On 08/12/2011 08:41 PM, Christian Thalinger wrote:
> On Aug 12, 2011, at 8:18 PM, Tom Rodriguez wrote:
>
>>> Well, it's the good old:
>>>
>>> @ 95 java.lang.invoke.MethodHandle::invokeExact (45 bytes) size>
>>> DesiredMethodLimit
>>>
>>> This seems to be the last recursive call that doesn't g
On Aug 12, 2011, at 8:18 PM, Tom Rodriguez wrote:
>> Well, it's the good old:
>>
>> @ 95 java.lang.invoke.MethodHandle::invokeExact (45 bytes) size >
>> DesiredMethodLimit
>>
>> This seems to be the last recursive call that doesn't get inlined. Setting
>> MaxRecursiveInlineLevel=0 makes
> Well, it's the good old:
>
> @ 95 java.lang.invoke.MethodHandle::invokeExact (45 bytes) size >
> DesiredMethodLimit
>
> This seems to be the last recursive call that doesn't get inlined. Setting
> MaxRecursiveInlineLevel=0 makes it go faster. I finally filed (a separate
> bug to keep
>>
>
> I wonder if this patch is not too much.
> If a big method is called through an invokedynamic + method handle
> then it will be inlined.
That's not how it works. The methods called by the adapter will still have to
pass normal inlining checks before being inlined so at worst you just en
Hi Chistian,
On 08/12/2011 11:44 AM, Christian Thalinger wrote:
> On Aug 11, 2011, at 11:07 PM, Charles Oliver Nutter wrote:
>
>> On Wed, Aug 10, 2011 at 11:02 PM, Charles Oliver Nutter
>> wrote:
>>> I've added bench/bench_fib_complex.rb. This runs the original fib
>>> along with three variation
On Aug 11, 2011, at 11:07 PM, Charles Oliver Nutter wrote:
> On Wed, Aug 10, 2011 at 11:02 PM, Charles Oliver Nutter
> wrote:
>> I've added bench/bench_fib_complex.rb. This runs the original fib
>> along with three variations:
>>
>> * One that uses constants for the literals 1 and 2 in the code
On Wed, Aug 10, 2011 at 11:02 PM, Charles Oliver Nutter
wrote:
> I've added bench/bench_fib_complex.rb. This runs the original fib
> along with three variations:
>
> * One that uses constants for the literals 1 and 2 in the code
> * One that dispatches to other Ruby methods for the <, -, and + cal
Hello everyone!
I have added a few new items to JRuby relating to invokedynamic. Let's
dive in, shall we?
1. invokedynamic-based dispatch for literal binary operators with RHS
a literal fixnum or float
This is actually on by default because it didn't seem to hurt perf
(much?) on JDK7, and it sho
31 matches
Mail list logo
