On Apr 30, 2011, at 9:27 AM, Charles Oliver Nutter wrote:
I have pushed a change to JRuby master that fails over to a simple
inline cache after one failed GWT. This is not how I would want to do
it long-term, but it does bring some benchmarks back in line with
non-indy JRuby. Specifically,
In the Smalltalk I am porting the solution they use is to just drop the
entire chain and let it
reform. The assumption would be that for any short time period in the
life of a program no sites
are megamorphic. the metric they use is the total amount of active code.
Since they actually
drop
On 05/01/2011 09:58 PM, Charles Oliver Nutter wrote:
On Sun, May 1, 2011 at 1:01 PM, Mark Roosmr...@roos.com wrote:
With respect to chaining gwt handles.
Any thoughts on at what depth the chain should be converted to some other
form of dispatch?
I am currently just letting them build
In
On 05/01/2011 11:01 PM, Mark Roos wrote:
In the Smalltalk I am porting the solution they use is to just drop
the entire chain and let it
reform. The assumption would be that for any short time period in the
life of a program no sites
are megamorphic. the metric they use is the total amount of
high polymorphic dispatch costs?
Sent by:
mlvm-dev-boun...@openjdk.java.net
On 05/01/2011 11:01 PM, Mark Roos wrote:
In the Smalltalk I am porting the solution they use is to just drop the
entire chain and let it
reform. The assumption would be that for any short time period in the
life
On 04/30/2011 11:13 PM, Charles Oliver Nutter wrote:
Well it seems like the GWT-based PIC could be a *great* success, at
least compared to falling back on a single-entry IC. I will shortly
commit another patch to JRuby master that provides a configurable GWT
chain size before giving up and
On Sun, May 1, 2011 at 1:01 PM, Mark Roos mr...@roos.com wrote:
With respect to chaining gwt handles.
Any thoughts on at what depth the chain should be converted to some other
form of dispatch?
I am currently just letting them build
In smalltalk it seems that around 10-20 inline tests are
On 04/29/2011 09:59 PM, Ola Bini wrote:
Hi,
Given that creating GWTs are expensive, is it a really bad idea to
create them and bind them on a cache miss then? My current logic for
call sites look something like this:
invoke call site
if fallback, check if current morphism is
On Sat, Apr 30, 2011 at 2:27 AM, Charles Oliver Nutter
head...@headius.com wrote:
I have pushed a change to JRuby master that fails over to a simple
inline cache after one failed GWT. This is not how I would want to do
it long-term, but it does bring some benchmarks back in line with
non-indy
Well it seems like the GWT-based PIC could be a *great* success, at
least compared to falling back on a single-entry IC. I will shortly
commit another patch to JRuby master that provides a configurable GWT
chain size before giving up and going to a simple IC, and the results
are spectacular.
On Apr 28, 2011, at 9:58 PM, Charles Oliver Nutter wrote:
I'm trying to figure out why polymorphic dispatch is incredibly slow
in JRuby + indy. Take this benchmark, for example:
class A; def foo; end; end
class B; def foo; end; end
a = A.new
b = B.new
5.times { puts Benchmark.measure
On 04/28/2011 09:58 PM, Charles Oliver Nutter wrote:
I'm trying to figure out why polymorphic dispatch is incredibly slow
in JRuby + indy. Take this benchmark, for example:
class A; def foo; end; end
class B; def foo; end; end
a = A.new
b = B.new
5.times { puts Benchmark.measure {
I think my strategy is going to be something like this:
* Bind first method encountered straight through with a new GWT
* Upon encountering nth new method, rebuild GWT chain to check first,
second, nth PIC-style
* For some N encountered methods, failover to a simple IC
Some variation of these
13 matches
Mail list logo
