I'm replying to you and JVM-L, so let me know if you have further trouble posting. Responses inline below!
On Tue, Nov 17, 2009 at 11:39 PM, daizi sheng <[email protected]> wrote: > I replied this post on JVML group, but it did not appeared there. > So I directly mailed you for the following questions. > > Have you ever tried to use group of stack values instead of > box primitive values and put them on heap? In CRuby and > other c/c++ implemented script engines, tagged pointer (or > union structure) are used. In JVM, this is not allowed, but we > can still use group of JVM stack values to represent a script value. > > For example, to represent a local variable, the following group > of value can be used, instead of a single reference to heap boxed > value. > > byte the_current_type; > int the_current_int_value; > double the_current_double_value; > Object other_case; > > We have tried this idea in a JVM based JavaScript engine. > Both performance improvement and less memory consumption > can be seed. Our current plan for reducing fixnum overhead is to build a better compiler. We've been working with Subbu Sastry on a new compiler for JRuby that can locally reduce fixnums and fixnum operations to primitive math, as well as inlining various pieces of logic *before* we emit JVM bytecode. There are many details to work out (maintaining a useful stack trace, for example) but the approach has promise. Some of the most problematic performance areas for us are heavy local math, math across only a couple Ruby methods, or numeric loops. In all these cases, a "better compiler" should be able to reduce that logic to primitive math rather than constructing fixnum objects for every math operation. It may very well be that using a "stack" of values like you suggest would help too, but it obviously complicates compilation a bit. And if we hoped to value-double along the call path, so we could pass a long and a RubyFixnum reference and possibly leave the RubyFixnum reference null, that means a lot of global changes. One thing we do right now is to have separate paths for literal integers on the LHS or RHS of a call. So for example, if 'a' is a Fixnum, 'a + 1' never stands up the 1 as a RubyFixnum object; it just passes it straight through to a RubyFixnum "op_plus" method that accepts a long. This reduces the number of Fixnum objects we have to have in flight at any given time, but it does not do anything to avoid the return value being a regular boxed fixnum. - Charlie -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=.
