On Tue, Oct 25, 2011 at 5:51 PM, Carter Cheng <cartercheng / gmail.com> wrote:
> Hi Charlie,
> I guess the difficulty I do have with certain modern bytecode systems is
> that on some level there do not match that well with the backends and IL
> structure of modern compilers (for example LLVM is heavily SSA based since
> this simplifies dataflow analysis due to lack of symbol replication).
> Concerning your point wrt to abstract versus more concrete bytecodesystems
> do you know of any references here where one can find discussion of the
> pro/cons of one of these versus the other. It would seem to me if the JIT
> systems can in principle deduce (infer) thinks based on the abstract IL or
> get some kind of "metadata" from the compiler frontend this would imply that
> the frontend information is not needed.

Disclaimer: I am not a compiler guy.

If the IL is too coarse-grained, then there's a limited granularity at
which the compiler can optimize. For example, if a particular IL
operation batches several lower-level operations together, it's
impossible to fold away duplicate operations at that lower leve. Now
of course the compiler could "know" what lower-level operations each
IL operation corresponds to, but that's basically the same as having a
lower-level IL to begin with.

For example...in JRuby's IR compiler, we have added more and more
low-level operations to allow folding more of them away. Some of them
access runtime state, some are for separate aspects of method lookup
like cache invalidation, some are low-level aspects of closure
variable access...none of these would be found in a higher-level IL
that only represents coarse-grained operations, but having the
lower-level IL allows us to e.g. fold away repeat type checks for
method cache invalidation. I don't think that would be possible if the
IL only contained a "send" instruction, since the optimizer would not
have enough visibility into what all "send" really does.

- Charlie