T
Twisted
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.
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.