On Apr 11, 2:09 am, "Chris Uppal" <chris.up...@[EMAIL PROTECTED]
> wrote:
> 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.
What I meant was that the type system prevents you from using "eval"
on anything but a function value. A function value is guaranteed to be
a piece of well-typed code, by the type system.
> 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.
Because you can't evaluate strings in my proposal, you can only
evaluate dynamically created functions, which are neccessarily
constructed by quoting functions (e.g. pu****ng functions onto the
stack) that the compiler has already seen. So your example becomes
sum = 0;
for (int i = 0; i < array.length; i++)
{
for (int j = i; j < array.length; j++)
{
eval(closure{sum += array[i] * array[j]});
}
}
return sum;
There are plenty of well-known optimizations that can be done to the
above code using functional optimization techniques, including pre-
evaluation.
The next logical step after introducing higher order opcodes is the
introduction of array/list processing primitives based. Iterating over
an array for an example could also be done using higher order
functions like "map" or "fold", which can be easily parallelized by a
compiler.
Christopher Diggins
http://www.cdiggins.com
|
