Re: Analyzer does not use stack map frames

Marcin,

  Which Analyzer you are referring to?
  I believe the Analyzer from analysis package is not using StackMap
data at all and that is on the purpose.
  If you want the StackMap, you can use AnalyzerAdapter from the
commons package.

  Hope that helps

  Eugene


2010/11/3 Marcin Rzeźnicki <[email protected]>:
> Hi all,
> I'd like to present here a quick rant :-) on Analyzer class. It seems
> not to use information from stack map frames generated by the compiler
> (when present) which leads to at least two awkward issues which are
> not easy to solve:
> - chop frames, if a frame is of F_CHOP type it communicates that
> variable goes out of scope. Analyzer does not handle this case
> seemingly (from its code I gather that it simply treats FRAME as no-op
> and tries to merge current frame with next frame, which is very bad if
> you want to know which variables are present at some point of code
> (and let's say, generate your stack map frames based on this
> information). Consider:
>
> for(T x : collection) { ... } *
>
> Here javac compiler (eclipse compiler differs AFAIK) generates
> "hidden" Iterator type variable (usually called i$) which it chops at
> *. If you try to generate some stack map frame yourself based on
> frames analyzer generated after * then what you see is that some
> variable i$ is present. It is misleading and can lead to number of
> issues. Let''s say that somewhere after * you have for(T y :
> another_collection) { }. Then javac frames may go as follows: append
> [Iterator], chop 1, append [Iterator] - if you modify code between
> these two loops and try to put correct frame yourself (to restore
> state) you may end up with a frame full[.., Iterator] - after which
> javac inserted append [Iterator] messes up the whole thing. You can
> resolve this by tracking all this yourself but that defeats the
> purpose of generic Analyzer because you need to redo much of its work.
> - types, Analyzer does not use type information which sometimes makes
> impossible to determine the real type of variable. Consider following
> code:
>
> List l;
> if (sth) l = new ArrayList(); else l = new LinkedList();
> javac generates frames append[List], same. Analyzer does not use type
> information from stack map frames but delegates determining of correct
> type to an Interpreter. But no Interpreter can resolve this issue
> fully. Interpreter's merge(Value, Value) is expected to find correct
> common supertype and fill this hole. It is not possible in Java where
> two types can have any number of overlapping interfaces. In the
> example above it is relatively easy to determine that, let's say,
> AbstractList is correct but consider: Serializable s if (sth) s = new
> ArrayList() else s = new SQLClientInfoException() //sorry for
> contrived example :-) - these runtime types share Serializable as well
> as Iterable in common and you have no way to determine which one of
> these two you should choose.
>
>
>
> --
> Pozdrawiam
> Marcin Rzeźnicki

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