The structure and content of StackMapTable attribute is described in the updated class fail format section of JVM specification. Though I don't think it is published anywhere and Sun's page only has reference to it. http://java.sun.com/docs/books/jvms/second_edition/jvms-proposed-changes.html So, I put a copy to Google docs at http://docs.google.com/fileview?id=F.a3678bb5-b6d0-4b6b-89e6-980238426f13
Bytecode frameworks, such as ASM [1] allow to recalculate stackmap content from scratch, as well as create it incrementally. Also, in bytecode version 50, you can omit stack map and verifier will fall back to the old algorithm, unless you'll specify JVM options -Xverify:all -XX:-FailOverToOldVerifier regards, Eugene [1] http://asm.objectweb.org/ On Oct 12, 4:39 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Dear list, > > I am currently carrying out tests to try to understand how the > StackMapTable attribute > of Java 1.6+ class files works. Although I find the JVM documents > quite comprehensive > and well-written in general, I think they fall short regarding the > StackMapTable attribute. > > I am quite puzzled by the fact that only the semantics is described > but not how it is intended > to be generated. I mean, it is obvious that one should not generate > the information for > each code offset as it would be far too large. Some experiments done > by diassembling code > compiled with javac seem to indicate that the information should be > generated only for > code offsets which are possible destination of a jump (either GOTO, > IFxxx, or exception catch). > It seems quite reasonable as besides the points, it is easy (and hence > fast) for the loader to > determine the types of the stack elements. > Is there a document / guideline to know for which offsets stack maps > should be generated ? > > Moreover, I have some trouble understanding how the class loader > treats the StackMapTable > attribute. Again, the semantics is quite clear to me, but I can not > find what the loader should do > if presented an incorrect attribute. I have tried to purposely > generate incorrect stack maps but > failed to make the loader complain about them (even with "java - > Xfuture"). > Did I miss something or is the loader designed to ignore flawed stack > maps and fallback on > its inference mechanism ? > > I will be grateful for any insight about the StackMapTable attribute. > > Regards, > > Xavier Clerc --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
