Re: Query about packaging extended analysis package

16/04/2014 00:32, Eliot Moss wrote:
> Dear ASM team (and other ASM email readers):
>
> The long-promised analysis package that supports backward analysis
> as well as forward, that supports "chained" analysis (where
> a new analysis uses results from a previous one), and that is
> otherwise substantially more general and extensible, is nearing
> completion.  So we have turned our thoughts to packaging and
> compatibility.

Good news!

> At present we are thinking that the best way to go is to offer
> this as a new subpackage under tree, say 'tree.analysis2'.  It
> could also be done as, say, tree.analysis.extended or something.
> We solicit your input on this.

Maybe tree.nanalysis (like java.nio vs java.io)? I don't have good ideas.

> Why a new package and not just a rework of tree.analysis?  Well,
> the factoring of code is different from one thing.  The current
> tree.analysis.Analyzer foresees running the same analysis on
> method after method -- certainly one reasonable pattern.  But our
> structure has a class called MethodAnalyzer that memoizes the
> control flow graph for a particular method, reducing space and
> effort for doing a series of analyses on the same method.  We
> also factor out the flow graph, and its construction, entirely,
> into flow graph helper classes, etc.  We further have our hierarchy
> of data flow values start with the notion of a single flow value
> at each program point.  The current tree.analysis.Frame is a
> particular kind of flow value -- highly structured to have a Value
> in each slot, etc., so we have an analog of that as a subclass
> of flow value.  Because forward and backward abstract execution
> are so different, we end up with forward and backward flow values,
> forward and backward frame flow values, etc.  We also make noticeably
> more use of generics to get good type checking of forward/backward
> and so on.
>
> So, our factoring and structure is different (though frames still
> use interpreters on Values, etc.).  The implication is that it is
> difficult to have Frame, Interpreter, etc., reside in our class
> hierarchy directly.  What we propose is a way from convert the
> old Frame objects into our correlate (ForwardFrameValue), and
> vice versa (if there is a possible need), so that old analyses
> need not be recoded to be used as the basis for chained analyses
> in our framework (though data copying is involved).  We will be
> recoding the existing analyses from tree.analysis so that these
> old friends will be available in the new framework as examples,
> and be of general utility.  New users of analyses should probably
> aim to use just the new package (or just the old one).  Using
> both probably incurs a space overhead (if converting Frames)
> and certainly a *code* space overhead.
>
> Which leads to another reason for making this a separate package:
> its size.  There is a lot of stuff here -- good stuff we think,
> but people should probably load it only if they really want to
> use it.  Our rough estimate of its incremental size, stripped
> of line number and local variable information, is about 100K bytes.
> This is perhaps not of great consequence on servers and larger
> clients, but maybe of more significance in embedded systems, etc.
>
> Another reason for doing a separate package is that it will be
> easier to add to the existing distributions since it disturbs
> the existing code base minimally (really not at all -- it uses
> it, but is not used by it).
>
> We invite your thoughts and comments as we move forward.  The student
> doing the work anticipates that the coding and testing will be done
> this semester.  Another faculty member and I will then need to find
> time to go over it very carefully and enforce consistent style (in
> all the senses of that) throughout.  But we do keep making progress
> and we feel the structure is much more sound and pleasing for future
> extensibility than where we were even a few months ago.

I'm fine with this approach. But I have one question regarding the
maintenance and evolution of this code: what will happen after the
student leaves this project? Do you have resources to fix bugs when they
are reported, add support for new JVM features, etc?

Eric

---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com

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