On Wed, Feb 18, 2004 at 02:59:24PM -0700, Andrew Huntwork wrote:
Depending on what kind of instrumentation you want to do, this is sufficient. For example, if you just want to know a complete call trace, you can insert the bytecode equivalent of the following at every method entry and exit:
log("entering/leaving foo.bar()V");
Except that you can't do that right at entry of the constructor (before the call to the superclass constructor). Try it. Or look at the code in the Helloifier:
It would seem that you can. See test.<init>: 0 ldc #1 <String "foo"> 2 invokestatic #44 <Method void log(java.lang.String)> 5 aload_0 6 invokespecial #42 <Method p()> 9 return
It seems to verify. I also just did a similar thing to every method in SpecJVM, and it still ran correctly. I think there aren't really that many restrictions on what you can do in a constructor. you just can't treat 'this' as an object until you make it one by calling super().
http://cvs.sourceforge.net/viewcvs.py/bcel/BCEL/helloify.java?view=markup
Look for "init". The code is there for a reason, and it's not sufficient.
I'd be interested to see an example where inserting ldc invokestatic at the beginning of <init> leads to unverifiable code. Maybe something to do with exceptions (since they screw everything up)? The example is pretty old code. Maybe Mr. Dahm was working around some bug in bcel? cvs history doesn't really tell me anything here.
Second, you could do some pretty complicated stack and control flow analysis. Here's something that's legal in bytecode but not in java:
if(...) super(foo); else super(bar);
Are you sure that's legal? The VM spec says:
"If a constructor body does not begin with an explicit constructor invocation and the constructor being declared is not part of the primordial class Object, then the constructor body is implicitly assumed by the compiler to begin with a superclass constructor invocation "super();", an invocation of the constructor of the direct superclass that takes no arguments."
Does you example begin with an explicit constructor invocation? I don't think it does. Is it allowed to call two different constructors for the same class on an object?
As I say, not legal in Java (which your passage refers to), but totally legal in bytecode.
My passage refers to the VM spec, so it's about byte code, not about the Java language.
but it's talking about how to compile this kind of code ("implicitly assumed by the compiler to begin with ..."), and it's in a chapter (2) called "Java Programming Language Concepts"...
The attached class has this <init>:
Method test() 0 iconst_0 1 ifeq 11 4 aload_0 5 invokespecial #10 <Method java.lang.Object()> 8 goto 15 11 aload_0 12 invokespecial #10 <Method java.lang.Object()> 15 return
it verifies just fine
OK. I never would have guessed from the spec.
Does anyone do that?
[No concrete examples mentioned]
A slightly different question is, how sure are you that your code will never be run on code that looks like my example? I recently saw a talk by Chad Woolley, the www.virtualmock.org guy. (http://www.virtualmock.org/presentations/) Apparently, he gets a chance to see how various bcel-derived programs worked together, including aspect-oriented tools (aspectj.org) and tools that figure out what parts of your code are executed by a test suite (code coverage). The point of the presentation is that they don't work together well in some cases. Apparently, each tool is thrown off by the weird (i.e., non-javac) code produced by the others.
In general, you'd be surprised how many sources of bytecode there are besides javac, so you'll eventually suffer if you concentrate too much on handling just that kind of code.
That depends entirely on what you are trying to do.
You're right, of course.
--
"I say to you that the VCR is to the American film
producer and the American public as the Boston
strangler is to the woman home alone."
-Jack Valenti, President, Motion Picture
Association of America, Inc., before
The House Subcommittee on Courts, Civil
Liberties, and The Administration of
Justice, August, 1982,
http://cryptome.org/hrcw-hear.htm--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
