Community
Participate
Working Groups
I20050920 JSR-202 (http://jcp.org/en/jsr/detail?id=202) defines a StackMap attribute. This new attribute should be supported at the JDT Core level.
It doesn't seem it is going to happend for 3.2M4. Any idea when?
I don't know if the code will be ready for M4. I am working on it, but it is more complicated than I thought initially. If the work can be completed in time for M4, it will be released for M4.
Thanks Olivier. If it would help there is implementation of the StackMapTable attribure in ASM bytecode framework (BSD-like license). See http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/asm/asm/src/org/objectweb/asm/attrs/
Ok, I'll put it back for M4 and I will reassess later. Thanks for the pointers.
Great! Just to clarify. In ASM 2.x stream we have support for reading and writing StackMapTable attribute but does not have service to recalculate frames. However such service is already implemented in ASM 3 beta stream (which is MUSTANT_SUPPORT branch there) and it passed regression test based on rt.jar from Java 6 snapshots.
Will be released after M4. I still have some performance issue. Right the generation of stack map table attributes takes about 4-5% of the compilation process. This is too much. We would like to reduce it to 2-3%. Most of the time is spent on collecting the data needed to generate the stack map frames. I can provide a patch based on M4, if someone wants to give it a try.
(In reply to comment #6) > Will be released after M4. I still have some performance issue. Right the > generation of stack map table attributes takes about 4-5% of the compilation > process. This is too much. We would like to reduce it to 2-3%. > Most of the time is spent on collecting the data needed to generate the stack > map frames. > I can provide a patch based on M4, if someone wants to give it a try. Thanks Oliver. Please provide a patch if it is not a big trouble for you.
Created attachment 31648 [details] Patch to apply on HEAD This patch needs to be applied on HEAD. There are still some issues with it: - handling of chaining gotos needs to be improved. Right now it creates stack map frames for positions that are unreachable. I doubt this will verify. - performance work: We would like to reduce the impact of this attribute to 2-3% instead of 4-5%.
(In reply to comment #8) > Created an attachment (id=31648) [edit] > Patch to apply on HEAD > > This patch needs to be applied on HEAD. > There are still some issues with it: > - handling of chaining gotos needs to be improved. Right now it creates stack > map frames for positions that are unreachable. I doubt this will verify. > - performance work: We would like to reduce the impact of this attribute to > 2-3% instead of 4-5%. Thanks Oliver. It would be good to have a tag or something that I could use to apply this patch (or have patch for M4 tag). Actually it is rather good thing that stack maps are generated for nonreaceable code because VM verifier will reject classes without stack maps at the branches (e.g. position after GOTO opcode) and it does no do any DFA analysys nor branch merging but just iterate trough all instructions sequentially checking resetting stackmaps at the branching points and checking stack states incrementally for the following instructions. So, the verifier itself is completely linear and that is what makes it much more efficient and less memory sensitive. Also see Eclipse bug about dead code at https://bugs.eclipse.org/bugs/show_bug.cgi?id=114894
I'll post a new patch once M4 is declared and the patch could be applied on the M4 tag of the jdt.core project.
For now, the patch can be applied successfully on top of version v_630 which should be the final jdt/core contribution for M4.
Thanks Oliver.
Fixed and released in HEAD. Regression tests are added in org.eclipse.jdt.core.tests.compiler.regression.StackMapAttributeTest. This cannot be activated in the UI yet since there is no compliance 6.0 available in the compiler preference page. However the batch compiler now supports -1.6 to enable the 1.6/6.0 mode.
Some of the tests fail with v_639 (three out of seven). May be a problem of setup on my machine.
I got the same three failures. Something has changed since I executed them last time. I'll check it.
Fixed and released. Maxime, could you please double-check once a build with this fix is available?
Will do.
Verified for 3.2 M5 using v_640, aka build I20060215-0800.
