AOP and debugging

Discussion in 'Java' started by Twisted, Mar 1, 2006.

  1. Twisted

    Twisted Guest

    AOP introduces new problems, especially involving debugging, but
    debugging may provide the solution, and especially on VM-implemented
    platforms (such as Java).

    Aside from possibly needing extra build/preprocessing steps, AOP
    further distributes the things that influence code semantics, making
    code harder to debug and the way a particular piece of code will
    execute harder to envision. (Previous leaps, e.g. from assembly to
    procedural, and thence to object-oriented, have had the same effect;
    the code no longer being "close to the hardware" has long been the #1
    complaint of "Real Programmers" against C++.) Debugging code whose
    behavior depends on stuff in several separate places promises to be
    especially hard.

    Yet one problem, how to implement AOP properly, may have its soliution
    in debugging. The most flexible and developer-friendly AOP systems
    would be run-time -- the aspect join points are hooked at runtime, on
    the fly, by trapping execution at join points and testing for and then
    possibly executing extra stuff.

    Isn't this precisely what debuggers have done for donkey's years, even
    in non-virtual-machine languages like C (using the hardware exception
    capability built into every CPU shipped since the early 90s)? What AOP
    needs to do strongly resembles trapping execution at some breakpoints,
    checking a watch expression here and there, and occasionally doing some
    extracurricular evaluations (possibly with side-effects) while paused
    at the breakpoint. All stuff routinely done in e.g. Eclipse while
    debugging Java code.

    Except you want to set and unset the breakpoints programmatically, and
    possibly even supply the watch and eval expressions at runtime.

    Perhaps the solution isn't to make AOP-friendly debuggers, or
    debugging-friendly AOP bolt-ons, or whatever; perhaps the solution is
    to actually combine them into a run time environment that is designed
    with both debugging and AOP in mind. I notice the overhead of attaching
    a debugger to a process in a modern environment is not significant; it
    seems there's basically none if you don't set breakpoints or other
    stuff. Which means there's potentially no (or almost no) up-front
    performance cost to making the runtime AOP+Debug capable. At which
    point, the same low-level trapping and extracurricular-execution
    capabilities can be used to do both, and perhaps to do them together,
    making debugging AOP-instrumented code not as bad as it otherwise might
    be.

    The only difference is that the AOP components of the code act like
    automatons with their hands on the debugger UI, programatically
    constructing breakpoints and hooking in watch expressions and evals,
    while the debugging components let the user do the same kind of thing
    manually. The AOP can even be implemented something like the
    metaphorical automaton above, by making instrumented join points
    suspend the running thread and notify a semaphore that wakes an
    AOPWorker thread (the way breakpoints suspend the running thread and
    notify the debugger UI thread, usually via loopback interface to a
    different process at that -- Eclipse's debugger definitely uses a TCP
    loopback and client/server architecture), which in turn applies
    "advice" (in AOP-jargon) and then wakes the original thread while
    sleeping itself. This architecture may help with the possible
    AOP+concurrency issues, too. (E.g. if a "situation" or "context" is
    maintained, e.g. a logfile, and needs to be protected against
    concurrent writes, traditional AOP requires the advice deal with
    locking this resource; AOP implemented this way using an AOPWorker
    thread is thread-safe automatically because other threads hitting an
    instrumented join point will block on our semaphore until our AOPWorker
    thread is done with its previous job. Separate AOPWorker threads per
    context are, of course, possible to keep thread-safety while improving
    performance in heavily AOP-instrumented code. Separately performing
    locking everywhere a context is accessed by advices when you go
    concurrent and need to make it thread-safe is an example of a
    cross-cutting concern putting extra bits of code everywhere anyway, so
    it's natural to solve it with AOP somehow too. One context, one thread
    seems sensible, and if contexts collide these AOP threads can
    synchronize their behavior the way one currently synchronizes
    business-logic threads.) And, of course, the AOP "thread"(s) can
    actually be fully separate processes, just as surely as Eclipse's
    debugger and the debuggee can be (and are) separate processes. This
    allows for a set of advice to be turned on and off as easily as one
    starts or stops a service from the Windows NT control panel, or for
    advice to come from a remote server, or ... the sky is really the limit
    here.

    AOP creates with it a whole new set of security concerns --
    crosscutting, naturally, since AOP by its nature allows reaching into
    existing code and altering its semantics; if you can put a "write
    comment to logfile" side effect into a function that didn't have one
    before with AOP, your adversary can put a "here's a backdoor, let's
    have fun changing bank balance objects to make me rich" side effect
    into a mission-critical function whose source code was audited by
    fifteen independent consulting firms that didn't find one in there just
    as easily. The solution may lie with using the client-server
    architecture for runtime AOP outlined above and ONLY allowing advice to
    come from a certain, trusted server (at least when it affects certain
    mission-critical methods and objects). This may be enforcable at the VM
    level; the server can be heavily guarded, both physically and against
    cyber-intrusion, and run only a limited, fairly easily auditable set of
    code, including all the system's advice; hostile "advice" would have to
    be introduced there to contaminate the system, rather than at any old
    spot in the system. (This is similar to how the independence day aliens
    were smart enough to force shield status changes to be authorized
    centrally, so that the mother ship had to be penetrated to bring down
    all the shields and messing with any other ship would have much more
    limited potential damage; this didn't save them, mind you, apparently
    because they'd been too busy inventing interstellar travel to develop
    basic cryptography and authentication technologies. Or maybe, having a
    hive mind, the need to limit access to trusted code/users was literally
    inconceivable to them?)

    I suppose this natural-seeming interconnection of AOP and debugging
    makes sense; after all, debugging is a cross-cutting concern. :)
    Twisted, Mar 1, 2006
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ravi Shankar Nair

    Regarding AOP - Performance and Security

    Ravi Shankar Nair, Dec 21, 2005, in forum: Java
    Replies:
    3
    Views:
    576
    Chris Smith
    Dec 21, 2005
  2. Santiago Aguiar

    AOP and metaclasses

    Santiago Aguiar, Feb 20, 2004, in forum: Python
    Replies:
    2
    Views:
    324
    John Roth
    Feb 20, 2004
  3. Rustom Mody

    AOP and pep 246

    Rustom Mody, Nov 1, 2007, in forum: Python
    Replies:
    13
    Views:
    541
    Kay Schluehr
    Nov 13, 2007
  4. George  Moschovitis
    Replies:
    0
    Views:
    115
    George Moschovitis
    Apr 18, 2005
  5. Luís Miguel Lourenço

    AOP and Ruby

    Luís Miguel Lourenço, May 24, 2005, in forum: Ruby
    Replies:
    4
    Views:
    140
    Lionel Thiry
    May 24, 2005
Loading...

Share This Page