ch.ethz.inf.iks.jvmai.jvmdi

Coding conventions

    AspectInterfaceImpl.c
    CodeJoinPointImpl.c
    ExceptionJoinPointImpl.c
    FieldJoinPointImpl.c
    FieldModificationJoinPointImpl.c
    hmap.c
    jmd.c
    JoinPointContext.c
    JoinPointLocation.c
    util.c

1. internal functions. Internal functions are always prefixed by a consistent smallcaps prefix. The prefix for FieldJoinPointImpl is fjp
2. external functions. External functions are used by other modules, are visible in the header files (e.g., in FieldJoinPointImpl.h) and are always prefixed by the CAPITALIZED module prefix. The prefix for external functions, for FieldJoinPointImpl is FJP
3. functions implementing JNI declarations from Java. They follow the standard javah naming scheme.

Some use-cases I played to verify the correctness of the implementation

1. a field set event is signalized by the debuggger

   - enter 'event' notification
     o enter 'FIELD_MOD_EVENT' switch case
         [ we obtain the AOP tag, call FillFromEvent]
         enter FMJP.Fill From Event
            1.enter FJP_Fill_fromEvent
   	     a) enter CodeJoinPoint.FillFromEvent
   		  - set AOP tag, set target to null,
   		  - call JoinPointContext.FillfromEvent
   			- fill JoinPointContext.depth
   			- fill JoinPointContext.state (with STATE_GOT_NOTHING)
   			- obtain JoinPointContext.location
   			- call JoinPointLocation.FillFromEvent
   			    - call JoinPointLocation.FillFromFrame
   				 -fill JoinPointLocation.executingBci
   				 -fill JoinPointLocation.executingMethod
     	     b) set FieldJoinPointImpl.field
   	     c) set FieldJoinPointImpl.value
           2. set FieldModificationJoinPoinImpl.newValue
     o  call 'AspectInterface.doOnFieldAccessJoinPoint
   

2. a method entry event, after being dispatched, askes for 'thisValue'

   - enter CodeJoinPointImpl.getThis().
      - call JoinPointContext.getThis();
        	- state is 'GOT_NOTHING'
   	- verification whether the 'executingMethod' is static (if yes, thisObject) = null
   	- for a non-static method, getLocalValue of the slot '0'
   	   - getLocalValue checks all the types; if all typecheck fail, then 'getLocalObject'
   

3. a method entry event, after being dispatched, asks for getArgs();

   - enter CodeJoinPointImpl.getArgs().
      - call JoinPointContext.getArgs();
        	- state is 'GOT_NOTHING'
   	- call do get localVariableInfo
   	   - init values for argValues,argSlots,argNames
   	   - call 'doGetLocalVariables' (to fill argSlots,argNames);
   	   - interate over the local variable infos and call 'getLocalValue(depth)'
   

4. a method entry event, after being dispatched, calls 'callerJoinPoint()'

   - enter CodeJoinPointImpl.getEnclosingJoinPoint();
     - call context.callerContext();
   	- create a new Context, with depth (-1);
   	- call 'doGetCallerLocationData(newContext.lcoation,thread,depth -1);
   	  - call jpc_GetFrameId(depth -1 )
   	  - call JPL_FillFromFrame(location);
           - return the new context
     - set the target (because this will be null  by default);
   

5. a methodentry event, after being dispatched, calls 'enclosingJoinPoint.getArgs()'

   
    -  SEE ABOVE on how the join point is created.
       - call JoinPointContext.getArgs();
        	- state is 'GOT_NOTHING' (because the context is fresh)
   	- call do get localVariableInfo
   	   - init values for argValues,argSlots,argNames
   	   - call 'doGetLocalVariables' (to fill argSlots,argNames);
   	   - interate over the local variable infos and call 'getLocalValue'
   
   

6. an exception join point is signalled

    - ai_GetExceptionThrowWatchTag is called
      - HMAP_Get on 'aiGetExceptionThrowTable'
   

An instance of this interface can be obtained by calling the method getAspectInterface() of a jvmai-provider (class DebuggerProvider).

Implementation

Bugs

• Startup ignores the openword/closed world assumption and the list of prefixes.
• Under JDK 1.4.*, when throwing an exception within the notificaion, exception events are wrongly sent to the debugger
• Under JDK 1.4.*, the 'GetThreadDepth' JVMDI function (name may be wrong), does not always work correclty.