> > 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.
You are right. All of them reduce to the same CFG loop structure. In
my rush to come up with an example, I made a very dumb statement about
while loops there! I stand corrected on that example. But, I was
just trying to make the point that JVM cannot see through all the
semantics of the dynamic language and there may be reasons to keep
that option open to exploit dynlang semantics.
> > 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.
Great! :) I used bad phrasing there -- I was using "you" in a generic
sense.
> > 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.
Yes, you are right, It does 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 :(
Okay. At this time, looks like maintaining "stack state" has to be
done in the dynlang vm.
Subbu.
> > 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.
