Christopher Diggins wrote:
> > It may well be that there are ways of extending the analysis the JVM
> > must do to allow higher-order bytecodes in the context of a state of
> > the art JITer, but I don't see any reason to expect that to be simple
> > at all -- nor any reason to expect it even to fit into the current
> > framework at all (it would be like adding eval(char *) to an
optimising
> > C compiler -- how can the compiler optimise code that is unknown until
> > runtime ?)
>
> This is an incorrect comparison. I am not proposing the execution of
> untyped strings, or untyped sequence but rather the execution of type
> functions generated through typed higher order instructions.
You keep talking about the type system, but (while I understand that it is
im****tant to be able to do this checking, and I agree that it is
significant
that you /can/ do the checking), I don't see the relevance here. The
issue is
the implementation technology used in generating native code, not the
technology used in static verification of bytecode.
Following the terms of my analogy, consider the following code:
sum = 0;
for (int i = 0; i < array.length; i++)
{
for (int j = i; j < array.length; j++)
{
eval("sum += array[i] * array[j]");
}
}
return sum;
the problem is not that the input to eval() might specify unsafe
operations, or
operations which wouldn't make sense, but that the compiler has no idea
which,
if any, of the variables are used in the loop; what kinds of
loop-transformation operations are valid; or even whether there are any
loops
at all there. It can't compile code it hasn't seen.
-- chris
|
