[...]
So, while it is true that the runtime of a dynamic language has to
transform the dynamic language to a typed bytecode, I think it also
means that the rntime has to implement any optimizations (inlining,
type guards, unboxing, EA, etc.) in the dynamic language VM which the
JVM cannot see through.
My first point is that the ability to statically type a dynamic
language is a silver bullet optimization. So it's a must have.
Agreed. But, it may not be possible to do this except as boxed types,
at least in Ruby.
Fixnum -> RubyFixnum
String -> RubyString
Hash -> RubyHash
etc.
So, when statically typed to the JVM, everything maps to non-primitive
"a*" bytecodes. So, an across-the-board unboxing set of optimizations
would have to be implemented in the VM to map directly to Java classes
where possible or explode the boxed objects where possible.
No. Implementing a RubyString is a bad idea.
It's better to add open methods to existing java.lang.String
instead of doing this kind of conversion.
And it's easy (at least not hard) to implement open method dispatch
using invokedynamic.
Otherwise, the runtime should not try to implement any optimizations
but a selective list known to improve the performance.
By example, implementing loop-unrolling is stupid, the JVM already
does a great job here.
I agree with you broadly. But, I wouldn't rule out loop-unrolling on
principle. It may be an useful tool in the arsenal at a more advanced
level. To give you a Ruby example, consider this:
(10..20).inject(0) { |s,i| s+i }
which computes the sum of numbers 10 through 20. Let us assume that
the Ruby VM is smart enough (which it will be one of these days) to
inline the inject code and the block code. After this inlining is
done, what you are left with is a while-loop.
i = 0
sum = 0
a = (10..20)
while (i< 10) do
sum += a[i]
i += 1
end
I am yet to catch up with the JVM and what it can do, but presumably
loop unrolling is only on for-loops, not while-loops.
Come on! It's the JVM not a PHP VM :)
The JVM detects backward reference in the bytecode so it works
with for, while, do-while, foreach loop, etc.
Here the Ruby runtime has to detect that the block
{ |s,i| s+i }
is a constant block. So it can be rewritten:
sum = 0;
for(i=10; i<20; i++) {
sum = sum + i;
}
So, assuming
the JVM doesn't unroll while loops, the Ruby VM would have to map this
to a for-loop, or unroll the loop itself. In this Ruby example (and
presumably more broadly -- for arrays, ranges, etc.), you might
instead implement a Ruby-specific opt that unrolls the loop and
computes the sum by exploiting Ruby array semantics without actually
doing a dataflow / cfg-based set of optimizations (inline method,
inline block, unroll loop, propagate constants), and this might be
faster and simpler to do in the Ruby dynopt VM than in the JVM.
Or if you implement code specialization inside Ruby (Ruby's open
classes makes it easier to do in Ruby than Java, I think, without
having thought too much yet), you might decide to unroll loops to get
the full benefits of specialization.
But, you are right that loop unrolling wouldn't be the first
optimization you would target, for sure .. it is one of the later
ones. But once you decide to implement a full dynamic language VM,
you might discover that many of these opts that might seem daunting
initially might not be as much once the optimizing VM infrastructure
is already in place.
I have already tried to implement a dynamic language :) [1]
And as I said, the JVM already unroll loops if it's possible.
So the question at 1.000.000 $ is which optimization should be
implemented ?
I would say inline caches (which most dynamic language VMs presumably
implement), method and block inlining, unboxing are probably
necessary, at least for Ruby. Beyond that, I would say it is language
specific.
Inlining cache is easy to implement with invokedynamic.
I use it as an example to explain how invokedynamic works.
the whole code use 3 slides.
But, I think the most crucial requirement in all this, which you also
identified in your previous email, is a setup that enables code
replacement and invalidation. Without relatively cheap invalidation
(either in the dynlang VM or via hooks into the JVM), most of the
dynlang VM opts will become expensive.
or worse you can't implement some optimizations.
By example, operator overflow (Fixnum -> Bignum) requires
a mechanism to exit from the current generated code.
If you don't have that, you can't typecheck because
you have an operator with a result type that depends on
the operands values and not the type of the operands.
Off the top of my head, without having spent a lot of time thinking
about this, Ruby VM opts could be considered to be a code versioning
technique on methods. Any condition that invalidates an existing opt
effectively bumps up a version number and invalidates all previous
code versions of that method. This mechanism is anyway needed for
implementing Ruby open classes.
Agree. JRuby already implement that. And I really hope that
soon the JSR 292 will provide a special handling for that.
So, all kinds of opt guards and type
guards effectively become a single code version guard at optimization
sites -- and you can then start thinking about optimizing the
placement of code version guards (ex: moving method version guards
outside loops, having coarse class guards on method entry, etc.).
or merging multiple guards etc.
The JVM is already not that bad here and there is some patches
to make things better.
So,
if code versioning can somehow be supported efficiently (or support
for it in the JVM is available -- GCing of code versions, code caches,
bytecode limits, etc.), it enables a bunch of opts. in the dynlang
VM. You can generate new versions of code and throw away old
versions.
The main problem here is how to extract stack values when
you throw away a code. Currently, the VM doesn't offer
any help :(
Subbu.
Rémi
[1] http://code.google.com/p/phpreboot/
--
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=en.
