5 Jun 2003 21:44
Re: the StackMap attribute
Mark Crocker <mcrocker <at> markcrocker.com>
2003-06-05 19:44:16 GMT
2003-06-05 19:44:16 GMT
On Mon, 26 May 2003 05:33:05 +0400, Igor Maznitsa wrote: I'm so sorry that this reply has taken so long, but I've been busy :) > How to use the StackMap attribute in BCEL? Could anyone show a simple > source example? I have interest to change an exist Java class what > contains methods with the attribute and I'd like to know how to update > the attribute when I have changed the code of a method... BCEL doesn't have any facilities for creating a new StackMap. The StackMap is there because they exist in J2ME MIDP class files and BCEL needs a structure to read the data into and write it back out from. Creating a StackMap from scratch is difficult. Calculating the StackMapEntry's requires a complex, iterative data flow analysis. To complicate things, Sun's preverifier has a number of bugs, so any StackMap generator would have to emulate Sun's bugs in order to work reliably. Even when you know what StackMapEntry's you want to include in a StackMap object, it is not entirely trivial to create the instance because you need to do all sorts of calculations to figure out the parameters in the constructor. In addition, you need to make sure that the ConstantPool has an entry for "StackMap". If this is all you want, I can post some code examples of how to do this. The open source version of the Purifier1 project (see http://www.markcrocker.com/~mcrocker/Computer/Purifier/) does was an attempt to create a substitute for Sun's preverifier, and, consequently, it does calculate and create StackMaps. However, the first attempt failed to duplicate all of Sun's idiosyncrasies because the Purifier1 project attempted to speed up the horrifically intensive calculations required of the data flow analysis by using a different analysis technique. Although the technique is MUCH faster, it did not always (~95%) produce the same results as Sun's preverifier. At that point, funding ran out and the project was moved to a commercial venture with an algorithm that follows Sun's algorithm more closely. The commercial version(Continue reading)
SB> I think the problem must come from the few operations you says you do,
SB> but that don't show up on the listing you sent ... Maybe you could send
SB> the whole thing.
No, problem appears even when I don't modify method. I.e. when I use
code in initial mail.
SB> Maybe one thing, I think you need to call classGen.update() once you
SB> changed the method ... But I don't think this will be the cause of your
SB> problem.
Yes, just tryed - still same exception.
Here is archive with class. Name of class is broken, but I don't
think, that this is reason of exception.
section 1 of uuencode 5.25 of file clazz.zip by R.E.M.
sum -r/size 64782/3098 section (from "begin" to "end")
sum -r/size 25249/2228 entire input file
SB> Simon.
SB> Konstantin Scheglov wrote:
SK> Btw, did you checked if your original (not instrumented) classes are
SK> acceptible? It is so stupid mistake, that you have to be genious to
SK> avoid it, at least I can not :))).
I tryied to post UUE with original class, but it seems, that UUE are
not accepted by mail list.
I am not sure, but I think, that original class itself is generated
directly in bytecode. It is EJB skeleton, generated by WebLogic. I
write profiler for Eclipse, it can handle almost all classes except
such already generated classes from WebLogic and CGLIB. For CGLIB I
don't have example, but for WebLogic I do.
I do try to check with _original_ class. And this exception ("Invalid
constant pool reference: 28088. Constant pool size is: 1024") appears
with it! I.e. I just load this class and create copy of each method
using MethodGen. I don't change code. Just copy, as you can see in
code. And even in this case I receive such exception. 
RSS Feed