Release of ASM4

Now that the JDK7 is out. I think it's time to release ASM4
(and starts to think what ASM next will be, jigsaw/module support anyone ?).

Is there anybody that think that there is still a bug
in the trunk that is a blocker or can we the release ASM4 ?

Rémi

On 07/30/2011 12:47 PM, Eric Bruneton wrote:
> Hi,
>
> thanks for this patch, I've committed it in the SVN repository
>
> Eric
>
> 12/07/2011 15:20, Ivo Anjo wrote:
>> Hello,
>>
>> I'm currently working on a project that heavily relies on the
>> tree.analysis.Analyzer class to understand and modify classes.
>>
>> As you might know, when creating the control flow graph for exceptions,
>> ASM calls analyzer.newControlFlowExceptionEdge(int insn, int successor),
>> and uses its boolean return to decide if it should consider the edge
>> valid or not.
>>
>> By default, this method simply returns "true". Because of the rules the
>> JVM specification uses to decide which exception handler is active --
>> for example if you add to the beginning of the exception table of a
>> method an entry that covers the entire method, and catches
>> java.lang.Throwable, none of the other handlers can ever be executed --
>> this simplification might detect control flow edges that would never be
>> possible.
>>
>> To implement the same rules the JVM uses, I do this:
>>      protected boolean newControlFlowExceptionEdge(int src,
>> TryCatchBlockNode tcb) {
>>
>>          for (TryCatchBlockNode handler : getHandlers(src)) {
>>              if (handler.equals(tcb)) return true;
>>              if (isSubTypeOf(tcb.type, handler.type)) return false;
>>          }
>>
>>          throw new AssertionError();
>>      }
>>
>> That is, I check if the current try catch block being "visited" is
>> subsumed by some other that came before it (since getHandlers() gives me
>> an ordered list, which is in the same order as the JVM uses).
>>
>> Unfortunately, the current code for newControlFlowExceptionEdge only
>> supplies the src and dst; basically, the current instruction and
>> insns.indexOf(tcb.handler).
>> This is unsufficient information to perform this analysis -- especially
>> since newControlFlowExceptionEdge might be called multiple times for the
>> same handler, so it is very hard to know which handler is being referred
>> to just by using the src and dst -- my first approach to this was
>> counting the number of calls to newControlFlowExceptionEdge, and then I
>> discovered that there can be multiple calls for the same block.
>>
>> This patch, then, adds a new method -- protected boolean
>> newControlFlowExceptionEdge(int src, TryCatchBlockNode tcb), which by
>> default delegates to the older newControlFlowExceptionEdge (which I
>> suggest be deprecated, or even removed for ASM 4). Even so, the two
>> methods can easily co-exist, and older code will still work perfectly;
>> and a simple one-line change inside analyzer.analyze, since the code
>> already knows that the current trycatchblock is.
>>
>> Hope it is acceptable, and thanks in advance,
>> Ivo Anjo
>

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws