Re: Re: [Findbugs-core] Fwd: toward ASM 4.0?

An interesting approach.  It seems reasonable to me.
Perhaps an abstract class with certain key "checking
and redirecting" method already implemented (maybe
even "final"?) would be even better, as previously
suggested.

Meanwhile ...

I find that there are slight extensions and tightening
of spec that would be helpful, and a considerable
extension I would like to undertake in the future.  For
each of these I have in mind the possibility of coding
them up and submitting the change at some point for
your perusal and approval.

1) I recently had the occasion to want to add a "wrapper"
exception handler to essentially every method, that would
cover all the original bytecodes, catch everything, make
a call to the note the exception, and rethrow it. This
was mostly straightforward except for one "gotcha": I had
to make the new visitTryCatchBlock call at exactly the
right point, which was (a) *before* the first bytecode
instruction had been visited, and (b) *after* all other
handlers that started at the same bytecode.  In the end
my solution was to add logic in each visitXXXInsn method
to see if we were about to visit the first bytecode --
harder than it should have been.  This suggests possible
"fixes", all of which might be useful:

1a) Have MethodWriter properly sort the handler table.
That way I could emit the handler information at any
time prior to visiting the relevant labels.  This seems
to me a good idea in general.  One would need the sort
to preserve the order of handlers that cover the same
range of bytecodes, since they give an order of matching
exceptions.  In fact, one might want to allow try-catch
blocks to be visited even after their labels have been
visited, but before visitMaxs (or some such).  This
would make it easy to place handlers that must come *after*
all others, as well as one that must come before, for
whatever reason.  I can't imagine the sort cost as being
typically very significant.

1b) More tightly specify the order of visiting try-catches,
labels, etc., and add visit methods for:
- before first try-catch
- after last try-catch
- before first byte code
There are related cases where being told we are shifting
from one "phase" to another would be helpful, such as
- before first field, after last field of a class
- before first method, after last method of a class
and so on.  Essentially, providing before/after "brackets"
to any list could be helpful.  The after-last ones are
harder to detect yourself, but before-first ones are easy
to add in readers and make writing applications easier.

Doing this suggests tightening the "grammar" of visiting.
For example, at a given code location it might require
any try-catch's to come first, then labels, then frames,
then local variables (whatever the order actually is --
this is just from memory).

Doing this well may require a bit of thought, but I think
it could clean up logic in code that uses ASM.

2) A long-standing lack in ASM is of backward-flow analysis.
In principle it should not be too hard to add, but requires
a kind of "clone" and rework of the forward-flow analysis
presently there.  I think it would be a great thing to have
since not all interesting uses of a tool like ASM can make
do with forward analysis alone.

3) The interpreter framework used in forward analysis could
make some additional useful distinctions.  In particular,
when coming up with new Value objects for abstract interpretation,
it would be helpful for some interpreters to know more about
the use of the particular value.  For example, I ran into a
case where I wanted to compute the origins of values, and
therefore I wanted to distinguish values coming from method
arguments from values arising from bytecodes.  And in the
case of arguments, I wanted to know *which* argument (say
by position number), and for those arising from bytecodes,
which bytecode.  This is additional information that simple
analyses could readily ignore but that would make it easier
to build more sophisticated analyses.

4) I recall some difficulty arranging to extend BasicInterpreter
and BasicValue in such a way as to make both extensions work
nicely together.  I would need to get back into that code to
reconstruct the issues and a good fix, but I do recall that it
was substantially a question of minor extensions to the
existing framework.  In the end, I had to copy and modify a
large swath of the existing analysis code, not a good software
engineering practice.

I would be interested in comments/reactions to any/all of
the above.  I find ASM really useful in my work and want to
help make it even better!

Regards -- Eliot Moss

-- 
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