[Binah-devel] aspect-oriented tracing

[Dexter A. <ve...@ia...>]

greets all.

After today's 362 aside about aspect-oriented programming, I asked Gary 
about the possibilty of load-time weaving of aspects into code-- 
thinking that we might be able to use it as an alternate or additional 
approach to tracing, rather than relying solely on JDI or 
org.eclipse.debug.  Gary suggested looking into JMangler, which I spent 
some time tonight reading about. 
(http://javalab.iai.uni-bonn.de/research/jmangler/)

The cool part is that it's a pretty complete *load*-time way to add code 
to compiled .class files.  So, in theory, the user could specify a 
.class file to load, and we go get it, add a bunch of binah-specific 
trace statements to it, say, before and after every synchronized method, 
and then pass the new bytecode to the class loader and run it.  Neat, eh?

Digging a bit deeper, it looks like adding any significant code is an 
absolute pain-in-the-ass.  Here's a snippet that takes the bytestream 
and adds a "System.out.println(msg);" line:

------------%<------------%<------------%<------------%<------------
final Type printStreamType = new ObjectType("java.io.PrintStream");
final Type[] argTypes = new Type[] { Type.STRING};
final int idx = cpg.addString(msg);

InstructionHandle first =
	il.insert(insertPoint,
		factory.createGetStatic( "java.lang.System",
                                             "out",
                                             printStreamType));
il.insert( insertPoint, new LDC(idx));
il.insert( insertPoint, factory.createInvoke( "java.io.PrintStream",
                                               "println",
                                               Type.VOID,
                                               argTypes,
                                         Constants.INVOKEVIRTUAL));
------------%<------------%<------------%<------------%<------------

Nasty, eh?  Of course, we'd probably not have to do more than add a call 
to our own code, Binah.traceMethod() or some such.  (Although I think 
there might be some potential issues with cutting across class loaders 
like that...?)

Now, wacky idea here, since the org.eclipse.debug library allows 
_dynamic_ class reloading, we could only do the run-time bytecode mangle 
dance at run-time, based on the user's selection of interest.  That is, 
if the user clicks "watch Employee locks", we could stop the VM, mangle 
the Employee.class file to add appropriate traceMethod() calls, then 
reload the Employee class and then resume the execution of the program. 
   This has the huge benefit of executing *no* trace code until the user 
says to watch something, and then only executing the minimal set needed. 
A bit far-fetched, yeah, but this is cool shit.

So anyway, spiffy-ness aside, I think there's probably all sorts of 
annoyance with this kind of run-time code modification, but if we can't 
get org.eclipse.debug to do what we want, I see this as a reasonable 
fallback.

-- 
Brian "Dexter" Allen   "Being nationalistic in the sense in which it is
www.luminousbeings.com  now demanded by public opinion would, it seems
ve...@ia...      to me, be for us who are more spiritual not mere
ve...@ac...          insipidity but dishonesty, a deliberate
                         deadening of our better will and conscience."
				               Friedrich Nietzche (1884)