DynComp Todo

  - Since DCRuntime is called from instrumented methods in the JDK, it
    must be in the boot classpath.  Since DCRuntime refers to many other
    classes in dyncomp, everything is currently put in the boot classpath.
    It would be better if that was not necessary.  It should be possible
    to change DCRuntime so that it doesn't have many external dependencies
    and only it needs to be placed in the boot classpath.

  - Properly handle Object methods.  Just ignoring them is not so good!
    The problem here is that we cannot add methods to Object.class (we should
    test this again, but I'm pretty sure that is the case).  We will thus
    need to replace these calls somehow (or perhaps provide a synopsis for
    their comparability).  We could argue that, for example, hashCode() and
    toString() shouldn't change comparability.

  - Support reflection.  Because of the additional argument, reflection
    finds the original code and not our code.  This means we don't
    accurately instrument.  This is the downside of adding the dcomp_marker
    argument to user code (which is necessary only so that we don't have to
    tell when calling between user code and the jdk)

    The dcomp_marker argument is added to the JDK code because we need
    to have access to the original uninstrumented JDK code.  We need
    this for our instrumentation code and also for the infrastructure
    of starting up the user program.  we thus create two versions of
    each JDK method (with and without the dcomp_marker argument).  The
    version without the dcomp_marker argument is unchanged.  The version
    with the dcomp_marker argument is instrumented.  This instrumentation
    approach to the JDK allows all classes except Object to be
    instrumented.

    It is not always possible to tell when examining a subroutine call
    whether or not it will call the JDK or user code (eg, an interface
    call could be implemented by either the JDK or user code).  The
    user code must thus also have the dcomp_marker argument so that it
    is call compatible with the instrumented methods in the JDK.

    A possible solution to this problem is to create two versions of each
    user method (with and without the dcomp_marker argument).  BOTH
    versions would be instrumented.  Normally the version with the
    dcomp_marker argument would be used.  But the version without the
    dcomp_marker argument would be available for reflection.  Since the
    names and arguments would be the same, no changes would be required
    to support reflection.

    If this works, it would be good to package up this instrumentation
    technique so that it can easily be used for other projects

  - We should provide a comparability synopsis for popular native
    methods.

  - Interface static final variables.  It seems that at least some of these
    are placed into their users and not fetched.  That works fine, but
    since we allocate a new tag each time it is referenced, we miss some
    comparability.  Not sure if anything can be done about it.  It also not
    clear that this is always the case but it is working for now.

  - It would be good to rerun some experiments on javac and see how well
    comparability works in reducing overhead and improving the results.
    If it doesn't work as well as we had hoped we should understand why.

Known limitations:

  - Integer arguments to MULTIANEWARRAY are made comparable to the
    corresponding indices only for 2-dimensional arrays. Higher
    dimensions are probably possible, but don't seem to be worth the
    effort.
