A couple quick thoughts from my end. JRuby does maintain a couple parallel stacks for "out of band" data that crosses method activations, and I have explored using a large array as well for closure scopes.
Currently, JRuby has a set of different-sized heap scopes for up to 4 local variables and then things failover into an array version. My experiment was to allocate one large array ahead of time and make all scopes be a single one that has an offset, size, and array reference. It would eliminate the cost of allocating scopes with N fields for N variables or allocating a scope plus an array. In practice, it did help allocation a bit, but since I still had to wrap the array in a structure to track the offsets it was a marginal improvement at best. At this point I'm still hoping for escape analysis to save me from too much allocation of boxed numerics (hard) boxed argument lists (easy, since they're usually inlinable), and closure scopes (impossible until JVMs can inline through a closure-receiving method to the closure itself). - Charlie On Mon, Jul 2, 2012 at 6:14 PM, Mark Roos <mr...@roos.com> wrote: > Hi Jim, some free from thinking. > > My implementation does not have a parallel stack so I am using the java > stack frame to hold > temps and pass arguments. Even so I can see how I would use a TaggedArray. > Instead of > using jvm var slots I would have one slot with a Tagged Array in it to hold > my method temps. > When invoking a callsite I would create a TaggedArray to hold the arguments > and pass that > to the invoke. I could cache the frames (assuming a cheap way to null the > contents of a > TaggedArray) to reduce object creation. > > So the question is then how to handle the callsite code selection. The > first GWT would > have to test if the object is a reference or a tag and route. Seems like it > would work. > > So other than extra overhead of using the arrays instead of the native stack > it will > probably work for me. > > I'll have to think some more > > regards > mark > > > _______________________________________________ > 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
