|Data flow analyzer for Java bytecode firstname.lastname@example.org (Paolo Maggi) (1998-07-20)|
|Re: Data flow analyzer for Java bytecode email@example.com (Sean McDirmid) (1998-07-21)|
|Re: Data flow analyzer for Java bytecode firstname.lastname@example.org (1998-07-24)|
|From:||Sean McDirmid <email@example.com>|
|Date:||21 Jul 1998 11:07:46 -0400|
|Organization:||University of Washington CSE|
Paolo Maggi wrote:
> I'm attending an Italian University and, for my graduation thesis, I
> need to design and develop a inter- and intra-procedural data flow
> analyzer for Java bytecode.
Start with the JVM spec. Then I guess the Dragon book is of some use
but its mostly building your own DFA engine from scratch. Are there
any publicly available DFA engines for traversing Java bytecode?
(Kimera is now proprietery :( )
> I'd also like to understand the way of constructing the control flow
> graph of a method when it contains jsr-ret blocks. Thank you very
> much for your help.
Yes, this was one of the most tricky parts when I was writing the
DFA engine for the Kimera Java bytecode verifier. Basically, the
JSR branch is a plain goto that pushes a return address. HOWEVER, the
complexity comes into play when the RET instruction is called on
a return address. If you are not doing verification then you
shouldn't worry about stale return addresses, this eliminates
alot of complexity. What you do need to worry about is "knowing"
the state of the locals in the "RET" block to facilitate the merge,
Sun does this a different way from the way we do. The problem
is that some local variables are not live in the blocks called
by the JSR instruction, so some kind of mask must be kept to
denote which local blocks are in use (so the merge can be done
Not to mention return addresses can be merged and you could have
an N-way merge from N+1 different blocks into to N different
Return to the
Search the comp.compilers archives again.