Re: Data flow analyzer for Java bytecode

Sean McDirmid <mcdirmid@cs.washington.edu>
21 Jul 1998 11:07:46 -0400

          From comp.compilers

Related articles
Data flow analyzer for Java bytecode p.maggi@studenti.to.it (Paolo Maggi) (1998-07-20)
Re: Data flow analyzer for Java bytecode mcdirmid@cs.washington.edu (Sean McDirmid) (1998-07-21)
Re: Data flow analyzer for Java bytecode s.doyon@videotron.ca (1998-07-24)
| List of all articles for this month |

From: Sean McDirmid <mcdirmid@cs.washington.edu>
Newsgroups: comp.compilers,comp.lang.java.machine
Date: 21 Jul 1998 11:07:46 -0400
Organization: University of Washington CSE
References: 98-07-153
Keywords: analysis, Java

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
correctly).


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
target blocks.


Sean
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.