Unresolved Implementation Issues
I should move most or all of these to the research pages.
- How can we identify entries into and exits out of dynamic
regions? Entries look easy, since annotations are only propagated
"downstream". What about multiple exits from a region? This would
be easy to do in the front end.
- How do we keep track of a variable annotated by make_static?
- To what extent can we verify annotations marked "unchecked"?
- How do we give the programmer feedback on the effect of his
annotations? We should at least output warnings when variables
are killed from the Iconst set. We should probably also
provide feedback about what replication is triggered by makeStatic.
- Define better pointer transitivity rules (static ptrs. vs. static
objects), and the corresponding annotations
- Globals
- Dynamically allocated objects
- Design of the static specializer (oracle)?
- Clustering
- Should we add a predicate-replacement phase? On each branch
following a decision what the predicate evaluated to is known (except
with fall-through cases). If the predicate is reevaluated anywhere in
the body of the decision construct, we could replace it with its
actual value. This would probably be most important for
switch statements. This optimization would require
information similar to what is collected to compute the reachability
conditions, but for all branches. Theorem provers are used to do this
in partial-evaluation systems (on the true branch of if
(d<10), a theorem prover could determine that (d<5) is
also true). It would require interaction with our analyses if we want
information propagated correctly past merges that will be split at
run-time.
- How will the compiler's optimizations affect the annotations? Will
the functions representing the annotations severely inhibit the optimizations?
Should we somehow mark the annotations to prevent this?
- To what extent, if any, can we allow phase-2 optimizations to operate on
run-time constants?
- How do we generate the specialized context switches to lazy units?
The eager and lazy state saving and restoring should probably be as
similar as possible, at least on the stitcher side.
- Establish timing methodology
- How to deal with rollover on cycle counter?
- How to run multiple times to overcome wall-clock
granularity problems?
- How to average times from multiple runs?
- Should we worry about cache effects?
- Design of instrumentation mechanism for dynamically compiled code?
Last updated April 10, 1997.