TaggedArrays

[Jim Laskey]

On 2012-09-12, at 11:35 PM, Charles Oliver Nutter <headius at headius.com> wrote:

> On Wed, Sep 12, 2012 at 9:06 PM, Charles Oliver Nutter
> <headius at headius.com> wrote:
>> This is very illustrative, thank you! I never got around to commenting
>> on your original email, so I'm taking some time now (I'm also doing a
>> talk on "high performance Ruby" at Golden Gate RubyConf on Friday, so
>> I'm looking at perf and numbers again).
> 
> Another problem/question/snag: clearing references?
> 
> By maintaining an artificial stack, we also incur the cost of clearing
> references on exit from each method. My exploration with JRuby has
> shown that reference-nulling accounts for a *substantial* part of the
> overhead of methods that require an artificial frame. JRuby already
> does have an artificial stack we use for methods we expect to need it,
> and even for methods that do nothing but clear that frame (and don't
> actually use it) the hit is pretty substantial...in my measurements,
> along with the cost of setting up the frame (we have to set a number
> of values whether they're used or not) clearing the frame on exit is
> approximately 1/3 of artificial stack overhead.

I agree, and would suggest using a frame based implementation to cover that.  Alternatively, taggedArray.fill will be optimized to use constant stores if the range is constant.

> 
> This is another place where being able to use JVM stack would be far
> better, since the JVM already handles GC-related stack effects for us.
> 

Agree.

> Thoughts? I assume where you are using TaggedArray you are clearing
> stack elements on method exit, right?
> 

We are currently only using TaggedArrays for instances.  Technology came too late for our first release to switch calling conventions.  In our case, the main concern was to avoid boxing out of frame.  And, since we want to play well with Java (one of the main goals of Nashorn), we use Java calling conventions with optimistic static typing.

> - Charlie
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev