Hi list,
sorry for not replying to John's earlier e-mail on this subject
(thanks for referring to my PPPJ'08 paper [1]). I think the
programmatic approach has merits compared to my annotation based
approach mentioned in that paper. One advantage of the annotations is
that they provide a hint to the compiler, in the PPPJ'08 paper I use
information on a class being stationary to change its vtable to one
where the methods are specialized to the proposed stationary value. A
problem with this is that the annotations become messy, which isn't
the case for a programmatic solution.
I think an improvement over John's proposal would be not to make
stationary knowledge appear by a call to "freeze" but to have an
abstract method provide this information, such as:
abstract class StationaryValue<T> {
private T value;
abstract boolean isStationary();
void setValue(T x) {
if(!isStationary()) {
value = x;
} else {
throw new StationaryValueException(...);
}
}
T getValue() { return value; }
}
A stable value would be a further refinement of this:
abstract class StableValue<T> extends StationaryValue<T> {
abstract boolean isStable();
}
One could create a stationary class that wraps a boolean and is
stationary/frozen when the value is true:
class StationaryIfTrue extends StationaryValue<Boolean> {
boolean isStationary() { return getValue().booleanValue(); }
}
>From this one could derive a class which has the properties of John's
original proposal:
class FreezableStableValue<T> extends StableValue<T> {
private final StationaryIfTrue frozen = new StationaryIfTrue();
private boolean isFrozen() { frozen.getValue().booleanValue(); }
boolean isStable() { return true; }
boolean isStationary { return isFrozen(); }
void freeze() { if(!isFrozen) frozen.setValue(Boolean.TRUE); }
}
The key advantage of this approach would be that a method such as:
void foo(StationaryValue<T> x) {
... // work
}
could be rewritten as:
void foo(StationaryValue<T> x) {
if(x.isStationary()) {
... // work
} else {
... // work
}
}
the isStationary call can be inlined and dominates the work. If the
isStationary call is true the top path of work can know a property of
x, such as that it is true in the case of a StationaryIfTrue class.
The second path of work could be a uncommon trap. The ability to
exploit this information is already present to a large extent in C2.
The key advantage of this approach over John's proposal is that being
stationary becomes useful even in the case of a non-constant
stationary value. A problem with the rewriting is that you could
"maliciously" detect it by watching when isStationary is called.
Thanks,
Ian Rogers
- Working for but not necessarily speaking on behalf of Azul Systems -
http://www.azulsystems.com/
[1] http://doi.acm.org/10.1145/1411732.1411746
--
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.
