o long/double syndrome
  - This seems to haunt us. There is still some bug with this.
    If HotSpot stuff is used to measure millisecs of hotspots,
    It fails with
       Exception in thread "main" java.lang.VerifyError: (class: jtest/Square, method: main signature: ([Ljava/lang/String;)V) Register pair 5/6 contains wrong type

o primitives. -- FIXED --
  - if longs/doubles are in method parameters, instrumentation failes.
    It has something to do with primitives bug below.
    - applied a workaround, that prevents instrumentation of 
      such calls with alt.jiapi.interceptor.InvocationInterceptor
    - Fixed this. Code wrongly calculated stack usage of method invocations.
      Instruction.stackConsumption() produces correct value for determining
      how far start of argument list resides.

o Cannot load java.lang.System. FIXED!!!
  - Applied workaround, that does not rely on InputStream.available();
  - Parsing of LongInfo did not take into account, that LongInfo
    reserves 2 entries in constant pool. @see JVMS 4.4.5

o primitives -- FIXED --
  - Somehow, if 'long' local-variables are used in a method, 
    bytecode verifier reports 'too large stack'. If think it is the
    same with 'double's.
        Max stack calculation was not correct; for long and double
        stack usage is +/- 2

o SwitchInstruction
  tableswitch has not been tested at all.

o interceptors
  - InvocationInterceptor. 
    Works with invokestatic and invokevirtual.
  - FieldInterceptor
      FieldHandler: (obsolete)
        Can only intercept public fields. This is a restriction of
        java.lang.Class.getFields(...) 
      AccessAdvisor:
        Can only interceptor method gets at the moment

o stack-usage -- FIXED --
  Instructions may consume _and_ produce content to stack. This is 
  not taken into account.
      Fix: Invocation.stackUsage()
      Fix: Instruction.stackUsage[getfield]
      Fix: JiapiMethod.updateMaxStack()

o Exception table
  end_pc of the exception table is exclusive. Following jad generated
  code fragment best describes the problem:
            try
            {
                b.bar2();
            }
            catch(Exception exception)
            {
                System.out.println("Got Exception");
                alt_jiapi_event_MethodEventProducer_15041882.methodExited("samples.event.Foo", "foo2");
            }
  So, method-exit routine is in effect only, if exception occurs.
  This is a bug in instrumentation framework. It does not take into
  account the presence of exception table.
  Instrumentation framework will be refactored in the future, so, for
  the moment, we can live with this one.

o Runtime
  When class(bytecode) is dumped to filesystem, it cannot be run with 
  another JVM. Runtime.getFieldValue(...) returns null, since it is
  not initialized. Thus, correct event-producer/interceptor is not
  available.
  
====